Vendor Lock-in beginnt nicht beim Lizenzvertrag – sondern wenn euer Produktionswissen in Systemen “gefangen” ist.

WISSEN | Industrial Data

Wenn über Vendor Lock-in gesprochen wird, geht es meistens um Hersteller, Lizenzkosten, proprietäre Schnittstellen oder teure Migrationen.

Alles richtig. Aber beginnt die eigentliche Abhängigkeit nicht deutlich früher?

Nämlich dann, wenn ein Unternehmen nicht mehr unabhängig von einem bestimmten System erklären kann, was seine eigenen Produktionsdaten eigentlich bedeuten. Klingt banal, oder?

In der Realität sehen wir aber immer wieder genau das. Ein Signal kommt aus der SPS. Eine Anwendung interpretiert daraus einen Maschinenzustand. Ein anderes System berechnet daraus OEE. Im Historian liegen ggf. gefilterte Rohwerte, manchmal noch mit Berechnungen. Im MES steckt weitere Logik. Das Reporting schaut nochmal etwas anders drauf.

Und irgendwann weiß niemand mehr wirklich:

Wo liegt eigentlich die Wahrheit?

Von Martin Waßmann – IT/OT Experts

Produktionsdaten sind nicht automatisch Information

Ein Wert, wie bspw. "1", ist erstmal nur ein Wert. Erst durch Kontext, also dessen Bedeutung und Rahmenbedingung, wird daraus Information.

Zum Beispiel:

• Maschine läuft
• Auftrag aktiv
• Störung liegt an
• Produktwechsel läuft
• Material fehlt
• Linie wartet auf einen Folgeprozess

Das Problem liegt auf der Hand:

Dieser Kontext steckt heute häufig nicht in den Daten selbst, sondern irgendwo in einer Anwendung:

• vielleicht in einem proprietären System, an das ihr mit Lizenzkosten mehrjährig gebunden seid,
  • Schnittstellenentwicklung langwierig und kostspielig,
  • schlimmstenfalls ist das System auch gar nicht geeignet, euer Problem zu lösen,
• vielleicht in einer SQL-Abfrage,
• vielleicht in einem MES,
• vielleicht in einem Dashboard,
• vielleicht in einer Excel-Datei,
• oder im Kopf eines Mitarbeiters, Teams oder Integrators, der die Lösung vor fünf Jahren verantwortet hat.

Solange das System läuft und niemand etwas verändern möchte, fällt das kaum auf. Spannend, interessant und teuer zugleich.

Der Lock-in zeigt sich häufig erst bei der nächsten Veränderung

Zum Beispiel wenn eine weitere Linie oder ein weiteres Werk angebunden werden soll.
Oder eine weitere Anwendung dieselben Daten benötigt.
Oder das MES ersetzt wird.
Oder ein Unternehmen plötzlich Produktionsdaten für AI oder Machine Learning nutzen möchte.

Dann beginnen Fragen wie:

Was bedeutet der Tag DB42.DBX17.3?

• Welche Einheit hat dieser Wert?
• Ist das ein Momentanwert oder ein Mittelwert?
• Wann gilt die Maschine als „Running“?
• Wie werden Micro Stops behandelt?
• Welche Signale gehören eigentlich zu dieser Anlage?
• Welche Logik wurde für OEE verwendet?

Und last but not least:
Wer weiß das?

Wenn die Antwort lautet:
„Das steht irgendwo im MES.“

oder:

„Das müsste unser Integrator wissen.“

dann besteht bereits eine Abhängigkeit.
Ganz unabhängig davon, welcher Hersteller auf dem System steht.

Vendor-neutral heißt: Das Wissen darf nicht in proprietären Anwendungen verschwinden

Natürlich kann und soll ein Unternehmen kommerzielle Systeme einsetzen. MES, Historian, SCADA, Analytics oder BI haben ihre Daseinsberechtigung. Problematisch wird es allerdings, wenn mit der Anwendung gleichzeitig auch das Wissen über die Produktion eingeschlossen wird.

Wenn also nur noch das MES weiß, wann eine Maschine produziert.
Wenn die Berechnung einer Kennzahl ausschließlich im Historian steckt.
Wenn nur eine proprietäre Datenstruktur beschreibt, welche Maschine zu welcher Linie gehört.
Oder wenn eine neue Anwendung zunächst die Logik eines bestehenden Systems nachbauen muss, um dieselben Daten überhaupt verstehen zu können.

Genau dort entsteht Vendor Lock-in.

Für mich bedeutet vendor-neutral deshalb nicht nur, zwischen verschiedenen Herstellern auswählen zu können. Es bedeutet, dass die grundlegende Beschreibung der Produktion nicht einem einzelnen Hersteller oder einer einzelnen Anwendung gehört.

Dazu gehören unter anderem:

• Datenmodelle
• Maschinen- und Anlagenstrukturen
• Semantik
• Einheiten
• Zustände
• Berechnungslogik
• Beziehungen zwischen Assets
• Qualitätsinformationen
• Zeitbezug
• Datenvalidität

Diese Informationen sollten möglichst offen, standardisiert und unabhängig von den Anwendungen verfügbar sein, die sie gerade nutzen.

Ein MES darf sie konsumieren.
Ein Historian darf sie speichern.
Ein Dashboard darf sie visualisieren.
Eine AI-Anwendung darf sie verwenden.

Aber keine dieser Anwendungen sollte der einzige Ort sein, an dem ihre Bedeutung existiert.
Denn wenn ich erst ein proprietäres System brauche, um meine eigenen Produktionsdaten zu verstehen, bin ich leider bereits abhängig.

Daten sollten möglichst viel von ihrer Bedeutung mitbringen

Genau deshalb halte ich einen anderen Ansatz für sinnvoll: Produktionsdaten sollten nicht nur transportiert werden, sondern sie sollten möglichst viel von ihrem Kontext und ihrer Bedeutung direkt mitliefern.

Eine Anwendung sollte idealerweise nicht zuerst ein sechsmonatiges Reverse Engineering durchführen müssen, bevor sie mit Produktionsdaten arbeiten kann.

Wenn eine neue Anwendung auf eine Maschine zugreift, sollte sie möglichst schnell verstehen können:

• Was ist das für ein Asset?
• Welche Signale existieren?
• Was bedeuten sie?
• In welcher Einheit werden sie geliefert?
• Welcher Zustand liegt vor?
• Wie aktuell sind die Daten?
• Sind sie valide?
• Welche Beziehungen bestehen zu anderen Assets?

Das ist aus meiner Sicht ein wesentliches Ziel moderner Industrial-Data-Architekturen.

Und genau an dieser Stelle werden Konzepte wie ein Unified Namespace (UNS) interessant.

Nicht weil MQTT automatisch alle Probleme löst. Tut es definitiv nicht.

Sondern weil Daten, Strukturen und Kontext damit von einzelnen Consumer-Anwendungen entkoppelt werden können.

Vier Fragen, die wir Kunden stellen

Wer herausfinden möchte, wie abhängig seine Produktionsdaten tatsächlich von einzelnen Systemen sind, kann mit vier einfachen Fragen beginnen:

1. Kann ich erklären, was meine Produktionsdaten bedeuten, ohne die jeweilige Anwendung zu öffnen?

2. Kann eine neue Anwendung dieselben Daten verwenden, ohne die komplette Logik erneut aufzubauen?

3. Kann ich ein System austauschen, ohne dabei Semantik, Berechnungen oder Produktionswissen zu verlieren?

4. Ist klar geregelt, wem Datenmodelle, Zustände und Berechnungslogik gehören?

Viermal „Nein“ ist aus meiner Sicht deutlich kritischer als eine teure Softwarelizenz. Auch ein einziges „Nein“ zeigt bereits ein immenses Problem auf.

Das eigentliche Ziel ist nicht weniger Software

Natürlich werden Unternehmen weiterhin MES, Historian, SCADA, BI, Cloud-Plattformen und spezialisierte Anwendungen einsetzen. Sollen sie auch!

Das Ziel einer vernünftigen Datenarchitektur kann deshalb nicht sein, alle Systeme abzuschaffen.

Das Ziel muss sein, die Bedeutung der Produktionsdaten nicht von diesen Systemen abhängig zu machen.

Dann kann ein Historian Historian sein.
Ein MES kann MES sein.
Eine AI-Anwendung kann auf dieselben Daten zugreifen.
Und wenn morgen eine bessere Anwendung kommt, muss das Unternehmen nicht wieder bei null anfangen.

Das ist für mich der entscheidende Unterschied.

Vendor-neutral bedeutet nicht, keinen Vendor zu haben.

Es bedeutet:

Das Wissen über meine Produktion gehört weiterhin mir.

Wie sieht das in der Praxis aus?
In unseren Case Studies zeigen wir, wie Produktionsdaten strukturiert, vereinheitlicht und für unterschiedliche Anwendungen nutzbar gemacht werden.

→ Zu den Case Studies

Häufige Fragen

Was bedeutet Vendor Lock-in bei Produktionsdaten?
Vendor Lock-in entsteht, wenn Produktionsdaten, ihre Bedeutung oder die zugehörige Logik so eng an ein bestimmtes System gebunden sind, dass andere Anwendungen sie nicht ohne zusätzlichen Aufwand nutzen können. Kritisch wird es insbesondere dann, wenn Semantik, Zustandslogik, Berechnungen oder Datenmodelle ausschließlich innerhalb proprietärer Anwendungen existieren.

Wie lässt sich Vendor Lock-in in der Produktion vermeiden?
Durch offene Schnittstellen, offene Standards und eine Datenarchitektur, bei der Produktionsdaten und ihr Kontext unabhängig von einzelnen Anwendungen bereitgestellt werden. Anwendungen wie MES, Historian, BI oder AI sollten Daten konsumieren können, ohne selbst der einzige Ort zu sein, an dem deren Bedeutung definiert wird.

Ist ein Unified Namespace automatisch vendor-neutral?
Nein. Ein UNS kann die Abhängigkeit von einzelnen Anwendungen allerdings deutlich reduzieren, wenn Datenmodelle, Semantik und Strukturen sauber definiert sind. Ein schlecht strukturierter UNS ohne Governance kann jedoch lediglich eine weitere technische Abhängigkeit oder ein neues Datensilo erzeugen.

Müssen Unternehmen dafür auf proprietäre Software verzichten?
Nein. Proprietäre Systeme können weiterhin sinnvoll eingesetzt werden. Entscheidend ist, dass grundlegendes Produktionswissen wie Asset-Strukturen, Semantik, Zustände und Berechnungslogik nicht ausschließlich innerhalb dieser Systeme existiert.

Warum ist das besonders für AI und Analytics wichtig?
AI- und Analytics-Anwendungen benötigen nicht nur Rohdaten, sondern verständliche und verlässliche Daten. Auch gefilterte oder durch Totzonenbereinigung veränderte Daten können problematisch sein. Sind Bedeutung, Einheiten, Zustände oder Beziehungen zwischen Assets nicht eindeutig verfügbar, muss dieser Kontext für jedes neue Projekt erneut rekonstruiert werden.

Woran erkenne ich, dass mein Unternehmen bereits einen Vendor Lock-in hat?
Ein deutliches Warnsignal ist, wenn eine neue Anwendung Daten nicht ohne Hilfe des bestehenden Herstellers oder Integrators verstehen kann. Gleiches gilt, wenn beim Austausch eines Systems Datenmodelle, Berechnungslogik oder Wissen über Maschinenzustände verloren gehen würden.

Ü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