Synchronisierung von Daten zwischen der Produktionshalle und Geschäftssystemen – Architektur, Fallstricke, bewährte Praktiken

Die Synchronisierung von Daten zwischen Produktionshalle und Geschäftssystemen wird häufig als Integrationsproblem beschrieben. In der Praxis ist sie jedoch vor allem eine Entscheidung darüber, welches Prozessabbild als verbindlich gilt. Von dieser Entscheidung hängen nicht nur die Effizienz des Informationsaustauschs ab, sondern auch die Art der Produktionsabrechnung, die Nachvollziehbarkeit von Abläufen, die Qualität der Planung sowie die Verteilung der Verantwortung nach der Inbetriebnahme der Lösung. Wird dieses Fundament zu allgemein definiert, kann die Kommunikation technisch zwar korrekt funktionieren, das Projekt führt jedoch dennoch zu manuellen Korrekturen, Interpretationskonflikten und kostspieligen Nacharbeiten.

Deshalb sollte das Thema wie eine ingenieurmäßige Aufgabe behandelt werden. Zunächst ist festzulegen, welche Daten ausschließlich der Beobachtung dienen, welche für Abrechnung und Bestätigung genutzt werden und welche eine ausführende oder formale Wirkung auslösen. Erst auf dieser Grundlage lassen sich Architektur, Systemverantwortung und Abnahmekriterien sinnvoll festlegen – ähnlich wie in einem strukturierten Projektmanagement.

Die Synchronisierung von Daten zwischen der Produktionshalle und den Geschäftssystemen ist längst keine Komfortfrage mehr. Heute ist sie eine Architekturentscheidung, die sich auf die Implementierungskosten, die Möglichkeit zur Produktionsabrechnung, die Qualität der Planung und den Umfang der Verantwortung nach der Inbetriebnahme des Systems auswirkt. Wenn Daten aus Maschinen, Linien und Arbeitsplätzen in den Geschäftssystemen mit Verzögerung ankommen, ohne eindeutigen technologischen Kontext oder außerhalb der Versionskontrolle des Prozesses, endet das Problem nicht bei eingeschränkter Transparenz. Das Team verliert die Möglichkeit, operative Entscheidungen belastbar zu begründen, Qualitätsabweichungen lassen sich schwerer erklären, und jede Änderung auf Produktionsseite erhöht das Risiko kostspieliger Anpassungen der Integration.

Die Ursache der Probleme liegt meist nicht im bloßen Auslesen der Daten, sondern darin, dass unbeantwortet bleibt, welcher Prozesszustand an welcher Stelle der Architektur als maßgeblich gelten soll. An diesem Punkt ist Synchronisierung nicht mehr nur der einfache Transport von Signalen zu ERP, MES, WMS oder einem Data Warehouse, sondern wird zu einem Bestandteil des Datenaustauschmodells im Industrieprojekt. Die Wahl zwischen direkter Kommunikation mit PLC, einer Zwischenschicht, einem Message-Broker oder einem ereignisbasierten Ansatz ist nicht nur eine technische Entscheidung. Sie legt fest, wer für die Reihenfolge von Ereignissen, die Vollständigkeit der Aufzeichnungen, den Umgang mit Verbindungsabbrüchen und die Wiederherstellung der Historie verantwortlich ist. In diesem Zusammenhang ist der Bereich der Industrieautomatisierung besonders naheliegend.

In der Praxis empfiehlt es sich, bereits zu Beginn des Projekts einfache Bewertungskriterien festzulegen:

• ob sich für jedes wesentliche Produktionsereignis seine Quelle und der Zeitpunkt seines Entstehens angeben lassen,
• ob klar ist, wer für die Bedeutung des jeweiligen Eintrags verantwortlich ist,
• ob eine Regel definiert wurde, nach der Informationen in den Geschäftssystemen als verbindlich gelten,
• ob die Folgen eines fehlenden, duplizierten oder verspäteten Kommunikationsereignisses beschrieben wurden.

Gibt es auf diese Fragen keine eindeutigen Antworten, steht das Projekt noch vor der eigentlichen Architekturentscheidung, selbst wenn die Kommunikation technisch bereits funktioniert.

Besonders deutlich wird das dort, wo die Produktion auf Ebene von Charge, Auftrag, Seriennummer oder Operationsverlauf abgerechnet werden soll. Ein an einem Arbeitsplatz erfasster Scan, die Zyklusbestätigung aus dem PLC und der Eintrag im Geschäftssystem können sich auf dasselbe Produkt beziehen. Ohne ein gemeinsames Modell für Zeit, Identifikatoren und Prozesszustände entstehen daraus jedoch drei unterschiedliche Versionen der Realität. Dann wird aus einem scheinbar kleinen Integrationsproblem eine Frage der Rückverfolgbarkeit von Produkt und Prozess. Es geht nicht nur darum, die Historie nach einer Reklamation rekonstruieren zu können. Es geht um tägliche Entscheidungen: Darf eine Charge freigegeben werden, kann ein Auftrag abgeschlossen werden, und beruht eine Abweichung auf dem Prozess, auf einer fehlerhaften Ereignisfolge oder auf einer verzögerten Synchronisierung.

Der Compliance-Aspekt tritt später in den Vordergrund, sollte aber nicht bis zum Schluss aufgeschoben werden. Wenn Daten aus der Halle dazu dienen, die Ausführung von Vorgängen zu bestätigen, den weiteren Fluss zu sperren, Material freizugeben oder Maßnahmen mit organisatorischer oder technischer Wirkung auszulösen, bekommt die Synchronisationsarchitektur Beweisrelevanz und wirkt sich auf die Sicherheit aus. Besonders deutlich zeigt sich das dort, wo Informationen nicht mehr nur den Zustand einer Maschine beschreiben, sondern die Abfolge von Tätigkeiten, die Bestätigung der Bereitschaft oder die Freigabe weiterer Schritte beeinflussen. Deshalb sollte bereits in der Konzeptphase zwischen Beobachtungsdaten und Daten mit ausführender Wirkung unterschieden werden. Ebenso ist festzulegen, welche Einträge lediglich verfügbar sein müssen und welche für Audit-Zwecke vollständig, konsistent und rekonstruierbar sein müssen. Gerade diese Unterscheidung zeigt am besten, ob es sich um eine gewöhnliche Integration oder um ein kritisches Datenaustauschmodell für Produktion und Geschäft handelt.

Wo Kosten oder Risiken am häufigsten steigen

Die Kosten von Projekten zur Datensynchronisierung steigen nur selten wegen der Kommunikation selbst. Meist beginnt das Problem mit der Annahme, dass sich alle Daten gleich behandeln und über denselben Weg, mit demselben Zuverlässigkeitsniveau und bei gleicher Verantwortungsverteilung übertragen lassen. Wenn sich in einem Datenstrom Meldesignale, Bestätigungen ausgeführter Vorgänge, Materialfreigaben und Informationen vermischen, die den weiteren Prozessverlauf beeinflussen, verliert das Team schnell die Kontrolle über die Folgen von Ausfällen und darüber, wer für einen Fehler verantwortlich ist.

Die Folge ist nicht nur eine höhere technische Komplexität. Hinzu kommen längere Abstimmungen, Nachbesserungen nach der Inbetriebnahme und Streit darüber, ob der Fehler in der Automatisierung, im übergeordneten System, beim Bediener oder in der Verfahrensanweisung liegt. Deshalb sollte die grundlegende Projektfrage nicht lauten: „Wie übertragen wir Daten?“, sondern: „Welche Folgen hat es, wenn Daten verloren gehen, doppelt übertragen werden oder voneinander abweichen?“ Wenn sich für jeden Informationstyp ein Verantwortlicher, die maßgebliche Quelle des gültigen Zustands, die zulässige Verzögerung und die Auswirkung eines Fehlers benennen lassen, bleibt die Architektur in der Regel beherrschbar. Ist das nicht möglich, kehrt das Risiko bei Abnahmen und im Betrieb zurück.

Ein zweiter Risikobereich ist die fehlerhafte Aufteilung der Verantwortlichkeiten zwischen den Systemen. Viele Integrationen sehen im Diagramm korrekt aus, versagen aber dann, wenn nach einem Linienstillstand, einer fehlerhaften Produktionsbuchung oder dem falschen Abruf einer Rezeptur der Ereignisablauf rekonstruiert werden muss. Wird die Prozesslogik ohne eindeutige Entscheidungszuordnung zwischen Steuerung, Middleware, Produktionsleitsystem und Business-System aufgeteilt, wird die Lösung schwer testbar und noch schwerer abnahmefähig. Jede Änderung auf der einen Seite beginnt Auswirkungen auf der anderen Seite auszulösen, und die Verantwortung für die Validierung verwischt.

Gute Praxis bedeutet daher nicht, möglichst alles mit allem zu verbinden, sondern die Zahl der Stellen zu begrenzen, an denen Entscheidungen mit ausführender Wirkung getroffen werden. Das ist wichtiger als die nominelle Verfügbarkeit einer Schnittstelle. Im Betrieb sagen der Anteil der Meldungen mit manuellem Korrekturbedarf, die Zahl uneindeutiger Zustände und die Zeit zur Klärung von Abweichungen zwischen Shopfloor und Business-System deutlich mehr aus.

Ein gutes Beispiel ist die Bestätigung des Abschlusses eines Produktionsvorgangs auf Basis eines Maschinenereignisses, das gleichzeitig die Auftragsausführung aktualisiert und den nächsten Schritt im Business-System freigibt. Wird die Übertragung wiederholt, verzögert oder auf halbem Weg unterbrochen, kann dies zu einer doppelten Produktionsverbuchung, fehlender vollständiger Chargenrückverfolgbarkeit oder zur Auslösung weiterer organisatorischer Schritte führen, obwohl der Vorgang tatsächlich nicht abgeschlossen wurde. Die Kosten entstehen dann nicht durch einen einzelnen technischen Fehler, sondern durch die Notwendigkeit, den Zustand manuell zu rekonstruieren, Daten abzugleichen und die Korrektheit der Einträge bei einem Audit oder einer Reklamation zu belegen. Kann das Team nicht im Voraus beschreiben, was geschehen soll, wenn eine Nachricht nicht ankommt, zweimal ankommt oder verspätet eintrifft, ist die Architektur unabhängig von der eingesetzten Software unreif.

In manchen Projekten reicht dieses Problem weiter bis in den Bereich der Cybersicherheit von HMI-/SCADA-Anwendungen. Das ist dann der Fall, wenn der Synchronisationskanal zum Weg für die Einspeisung von Daten wird, die Rezepturen, Parameter, Verriegelungen oder Bereitschaftsbestätigungen beeinflussen. Dann geht es nicht mehr nur um die Qualität der Integration, sondern auch um die Möglichkeit unbefugter Zustandsänderungen im Prozess, den Verlust der Nachvollziehbarkeit sowie die fehlerhafte Identifikation des Benutzers oder Systems, das den Vorgang ausgelöst hat. Wenn synchronisierte Daten Funktionen der Maschine, die Startsequenz oder die Bedingungen für ein sicheres Anhalten beeinflussen, ist die Integration keine reine IT-Aufgabe mehr und erfordert eine gemeinsame Risikobewertung. Je größer die ausführende Wirkung der Daten ist, desto weniger Raum bleibt für Vermutungen, nicht dokumentierte Ausnahmen und provisorische Umgehungslösungen.

Wie man das Thema praktisch angeht

Am sichersten ist es, die Datensynchronisation nicht als einzelne Verbindung zwischen Systemen zu betrachten, sondern als Architekturentscheidung mit operativen und finanziellen Folgen. Die teuersten Fehler entstehen meist aus der Annahme, dass „Daten aus der Produktion“ einheitlich seien und sich mit einem einzigen Mechanismus verarbeiten ließen. Tatsächlich gelten für den aktuellen Maschinenzustand andere Anforderungen als für einen Produktionsauftrag und wiederum andere als für die Historie von Chargen, Alarmen oder Umrüstungen.

Der erste Schritt sollte daher darin bestehen, drei Punkte voneinander zu trennen: Was soll synchronisiert werden, mit welcher zulässigen Verzögerung und welche Folgen haben Fehler, Ausfall oder doppelte Erfassung. Diese Aufteilung strukturiert die weiteren Entscheidungen. Wenn Verzögerungen oder Inkonsistenzen ausschließlich das Reporting betreffen, kann ein Modell gewählt werden, das gegen kurzfristige Abweichungen robust ist. Wenn sie jedoch die Chargenfreigabe, die Rohstoffverbuchung, die Bestätigung eines abgeschlossenen Arbeitsschritts oder die Entscheidung des Bedieners beeinflussen, ist ein höheres Maß an Kontrolle, Nachvollziehbarkeit und Behandlung von Ausnahmesituationen erforderlich. Erst dann ist die Wahl des Kommunikationsmechanismus wirklich sinnvoll.

Der nächste Schritt ist die Beschreibung der Verantwortungsgrenzen vor Beginn der Implementierung. Es muss festgelegt werden, welche Quelle für Auftragskennungen, Rezepturen, Chargen, Bediener und Produktionsereignisse führend ist, wo der Eingang der Daten bestätigt wird und wer Konflikte entscheidet. Ohne diese Festlegungen gleichen sich die Systeme zufällig ab: Dasselbe Produkt erhält unterschiedliche Zeitstempel, zwei Systeme berechnen denselben Stillstand unterschiedlich, und manuelle Korrekturen hinterlassen keine Entscheidungsspur. Die Kosten eines solchen Ansatzes erscheinen nicht sofort im Integrationsbudget. Sie kommen später zurück – als Diagnoseaufwand, Auditprobleme und Streit darüber, welche Anwendung den verbindlichen Zustand abbildet.

Ein gutes Maß für die Reife einer Lösung ist, ob sich für jedes kritische Datenobjekt genau ein Ort seiner Erzeugung, ein eindeutiger Identifikator, eine Regel zur Versionierung sowie ein Verfahren für Korrekturen benennen lassen. Wenn sich diese Antworten nicht kurz und eindeutig festhalten lassen, befindet sich das Projekt höchstwahrscheinlich noch immer auf der Ebene von Annahmen.

In der Praxis zeigt sich das besonders deutlich bei der Rückmeldung von Auftragsfortschritt und Materialverbrauch. Erwartet das Geschäftssystem nach jedem Arbeitsschritt eine Bestätigung, während aus der Produktion nur ein aggregiertes Ergebnis am Ende der Schicht übermittelt wird, sind die Daten formal zwar synchronisiert, operativ entsteht jedoch eine Lücke. Die Reihenfolge der Ereignisse lässt sich dann nicht belastbar rekonstruieren, Abweichungen können keiner konkreten Charge zugeordnet werden, und es bleibt unklar, woher die Bestandsdifferenz stammt. In einer solchen Konstellation reicht das Thema Synchronisation in den Bereich der Rückverfolgbarkeit von Produkt und Prozess hinein. Soll das System später zur Ursachenanalyse bei Nichtkonformitäten, zum Chargenrückruf, zur Bearbeitung von Reklamationen oder zur Absicherung einer Qualitätsentscheidung dienen, muss nicht nur der Nachrichtentransport, sondern der vollständige Rückverfolgbarkeitspfad ausgelegt werden: wer das Ereignis erzeugt hat, auf Basis welcher Materialkennung, in welchem operativen Kontext und ob sich der Eintrag einem konkreten Prozesszustand zuordnen lässt.

Erst auf dieser Grundlage lässt sich sinnvoll entscheiden, ob die Lösung auf einer Middleware-Schicht oder auf dem direkten Datenaustausch mit den Steuerungen beruhen sollte. Die Frage, ob MQTT, OPC UA oder die direkte Kommunikation mit PLC die richtige Wahl ist, lässt sich nicht fundiert beantworten, solange nicht geklärt ist, ob der Schwerpunkt auf der Zustandsabfrage, der Übergabe eines Befehls, der Historisierung von Ereignissen oder der Wahrung einer konsistenten Datenbedeutung zwischen den Systemen liegt. Hilfreich ist hier der Vergleich der Ansätze, die im Beitrag Kommunikationsprotokolle in der Industrieautomatisierung beschrieben werden. Hat eine Information Beweischarakter, dient sie der Abrechnung oder beeinflusst sie die Freigabe eines Produkts, genügt es nicht, dass sie übertragen wurde. Sie muss sich auch verifizieren, rekonstruieren und belastbar vertreten lassen.

An dieser Stelle kommt auch die Risikobeurteilung ins Spiel, allerdings nicht als abstrakter formaler Schritt. Gemeint ist die praktische Bewertung der Folgen einer fehlerhaften Synchronisation für Prozess, Qualität und die Verantwortlichkeiten der Beteiligten. Sobald synchronisierte Informationen operative oder formale Wirkungen auslösen, sollte man sie wie andere Entscheidungen im industriellen Umfeld behandeln: mit beschriebenen Fehlerszenarien, klar benanntem Entscheidungsverantwortlichen, einer Methode zur Erkennung von Abweichungen und einem Verfahren für den sicheren Übergang in einen Betrieb mit eingeschränktem Vertrauen in die Daten. Diese Denkweise wird durch die Risikobeurteilung in der Praxis gut unterstützt.

Worauf bei der Umsetzung zu achten ist

In der Umsetzungsphase entstehen die meisten Probleme nicht durch die Kommunikation selbst, sondern durch die falsche Annahme, dass technisch verfügbare Daten automatisch auch für operative, abrechnungsrelevante oder qualitätsbezogene Zwecke geeignet sind. Genau an diesem Punkt ändert das Projekt meist seinen Charakter: von einer reinen Informationsintegration hin zu einem Mechanismus, der Planung, Chargenfreigabe, Leistungsmeldung oder Produktionsabrechnung beeinflusst. Wenn das Team dies vor dem Go-live nicht ausdrücklich benennt, kommen die Kosten später in Form von Workarounds, manuellen Korrekturen und Diskussionen darüber zurück, welcher Wert der richtige ist.

Deshalb muss vor der Abnahme eindeutig festgelegt werden, welche Daten ausschließlich informativen Charakter haben, welche eine Geschäftsentscheidung auslösen und welche operative oder formale Folgen haben können. Je größer die Tragweite der Wirkung, desto höher sind die Anforderungen an Rückverfolgbarkeit, Gültigkeitszeit der Daten, Umgang mit Verzögerungen und Verantwortung für Korrekturen. Diese einfache Unterscheidung bringt in der Regel sowohl die Architektur als auch den Testumfang in Ordnung.

Die zweite Falle betrifft die Grenze zwischen einem Integrationsprojekt und einem Projekt aus dem Bereich der Automatisierung. Die Frage nach der Synchronisation führt recht schnell zur Frage nach Kommunikationsprotokollen in der Industrieautomatisierung, aber erst dann, wenn der Erfolg der Umsetzung davon abhängt, wie Daten aus Geräten gewonnen werden, wie gut Zeitstempel sind, welche Bedeutung Variablen haben, wie die Zustellung bestätigt wird oder wie sich das System bei Verbindungsverlust verhält. Dann handelt es sich nicht mehr um eine unterstützende technische Detailentscheidung. Die Entscheidung, ob eine Zwischenschicht genutzt oder näher an den Steuerungen kommuniziert wird, verändert den Testumfang, die Verantwortung des Integrators und das Risiko eines Prozessstillstands bei fehlerhafter Implementierung.

Hilfreich ist hier ein Kriterium: Wenn geklärt werden muss, woher ein Wert stammt, wann er ermittelt wurde und ob es sich um einen Zustand, ein Ereignis oder ein Berechnungsergebnis handelt, hat das Thema bereits die Ebene eines Datenaustauschmodells erreicht und betrifft nicht mehr nur die einfache Kopplung von Systemen. Diesen Punkt sollte man früh erkennen, denn davon hängen sowohl das logische Design als auch die Durchführung der Abnahmen ab.

Gut veranschaulichen lässt sich das an der Synchronisation von Informationen über die Auftragsausführung aus mehreren Fertigungszellen mit dem Geschäftssystem. In der Demonstrationsphase kann alles korrekt wirken: Die Werte sind sichtbar und werden fehlerfrei aktualisiert. Das Problem zeigt sich erst bei der Wiederaufnahme der Produktion nach einem Stillstand, bei einem manuellen Eingriff des Bedieners oder bei einem Chargenwechsel ohne vollständigen Abschluss des vorherigen Zyklus. Dann wird deutlich, ob die Architektur zwischen fehlenden Daten und dem Wert null, zwischen einem neuen Eintrag und einer Korrektur sowie zwischen aktuellem Zustand und historischer Information unterscheidet. Ist das nicht der Fall, beginnt das Geschäftssystem, Ausführungen doppelt zu erfassen, den Chargenkontext zu verlieren oder Produktion zum falschen Zeitpunkt zu verbuchen. Das ist keine kleine technische Ungenauigkeit, sondern ein realer Umsetzungskostenfaktor: zusätzliche Abnahmetests, Überarbeitung des Mappings, Abstimmung der Daten zwischen Produktion und Planung und mitunter auch ein eingeschränktes Vertrauen in Managementberichte.

Besondere Vorsicht ist geboten, sobald die Integration in die Betriebsbedingungen der Maschine eingreift oder von der in ihrem Umfeld installierten Infrastruktur abhängt. Wenn das Nachrüsten von Kommunikationseinrichtungen, Schaltschränken, Hilfsstromversorgungen oder Potenzialausgleichsverbindungen die Ausführung der Installation verändert, die Aufteilung der Stromkreise beeinflusst oder Eingriffe in die Ausrüstung der Maschine erforderlich macht, muss dies auch unter dem Gesichtspunkt der elektrischen Sicherheit und der technischen Dokumentation bewertet werden. Es geht dabei nicht um Formalismus, sondern um eine klare Abgrenzung der Verantwortlichkeiten: Was ist noch Teil der Datenintegration, und was wird bereits zu einer Änderung an der Maschinenlösung und erfordert eine gesonderte Bewertung. Wenn die Umsetzung Eingriffe in Stromversorgungssysteme, Schirmung, Erdung oder in für den Maschinenbetrieb wesentliche Stromkreise erfordert, geht das Thema über die Anwendungsebene hinaus und sollte unter Beteiligung der für Automatisierung, Elektrotechnik und Konformität verantwortlichen Personen bearbeitet werden. In diesem Zusammenhang kann der Beitrag über Anpassung von Maschinen an die Mindestanforderungen hilfreich sein.

Die sinnvollsten Umsetzungen sind meist technisch weniger spektakulär, begrenzen dafür aber das Haftungsrisiko besser. Das Team sollte nicht nur beantworten können, wie die Daten fließen, sondern auch, was bei ihrem Ausfall, bei Verzögerungen, Widersprüchen oder beim Zurücknehmen einer Korrektur geschieht. Wenn sich diese Antwort nicht in der Lösungsbeschreibung wiederfindet, bleibt das Projekt unvollständig – selbst dann, wenn die Kommunikation unter Testbedingungen korrekt funktioniert. Über die praktische Qualität der Architektur entscheidet nicht der nominale Datenfluss, sondern das Verhalten unter Randbedingungen, die später über Wartungskosten, Abnahmezeit und die Nachvollziehbarkeit der getroffenen Entscheidungen bestimmen. In vielen Fällen lohnt es sich, diesen Zustand durch ein Sicherheitsaudit für Maschinen und Produktions- und Technologielinien zu überprüfen.