Digital Thread — derselbe «Name» über Systemgrenzen hinweg

Bei einem Digital Thread geht es nicht darum, Daten an einem Ort zu sammeln. Verteilte Systeme müssen dieselben Objekte mit denselben Namen bezeichnen und deren Beziehungen und zeitlichen Verlauf nachvollziehbar machen. Werden Daten nur gesammelt, entsteht ein Datensumpf. Sind die Namen durchgängig verknüpft, entsteht auch über verteilte Systeme hinweg ein Thread.

Dieser Artikel gliedert den Thread in die drei Stränge Identität · Beziehungen · Zeit und erläutert technisch, wo sie unterbrochen werden und wie sie sich wieder verbinden lassen. Die Beispiele stammen aus einer realen Implementierung der PlantPulse Platform, die Prinzipien gelten jedoch für jeden Technologie-Stack in jeder Fabrik.

Zielgruppe

Ingenieure, die MES · ERP · Historian · CMMS miteinander verbinden, Entwickler von Datenmodellen für Fabriken und alle, die sich schon einmal gefragt haben: «Alle Daten sind vorhanden – warum erhalte ich trotzdem keine Antwort?» Als ergänzende Lektüre empfiehlt sich KI in der Fertigung — was Fabrikdaten vom Modell verlangen.

1. Was ein Digital Thread ist – und was nicht

Ein Produkt wird konstruiert, sein Prozess festgelegt, ein Fertigungsauftrag erstellt, eine Prüfung durchgeführt und bei einem Anlagenausfall eine Instandhaltung veranlasst. Jeder Schritt wird von einem anderen System erfasst. Der Digital Thread ist der Faden, über den sich diese Aufzeichnungen rückwärts verfolgen lassen.

Wird die Frage «Warum ist die Ausschussquote dieses Loses gestiegen?» über den Thread beantwortet, ergibt sich folgende Kette:

불량 로트 ─(어느 작업지시?)─▶ 워크오더 ─(어느 설비, 언제?)─▶ 설비 · 시간 구간
    ─(그때 그 설비의 신호는?)─▶ 태그 시계열 ─(상류는?)─▶ 공급 설비 · 유틸리티
    ─(그 설비의 정비 이력 · 절차서는?)─▶ 문서

Jeder Pfeil steht für einen Join über eine Systemgrenze hinweg. Ist nur einer davon unterbrochen, endet die Abfrage an dieser Stelle und jemand beginnt, mehrere Excel-Dateien zu öffnen und die Daten manuell abzugleichen.

Häufig verwechselter Begriff	Unterschied
Digitaler Zwilling	Ein Zwilling ist das Zustandsmodell eines einzelnen Objekts: Wie geht es dieser Pumpe gerade? Ein Thread ist eine Referenz, die Objekte miteinander und über die Zeit hinweg verbindet: Was versorgt diese Pumpe, für welchen Fertigungsauftrag wurde sie eingesetzt und was geschah zu diesem Zeitpunkt? Auch mehrere Zwillinge bleiben voneinander isolierte Inseln, wenn der Thread fehlt
Data Lake	Ein Lake dient der Speicherung. Selbst wenn alle Daten an einem Ort liegen, können sie nicht miteinander verknüpft werden, solange ihre IDs voneinander abweichen
Integrationsplattform	Dass ein Produkt alle Funktionen bereitstellt, ist etwas anderes, als wenn mehrere Systeme dieselben Namen verwenden. Beim Thread geht es um Letzteres

2. Wo der Thread unterbrochen wird

In der Praxis lässt sich ein unterbrochener Thread fast immer auf eine von vier Ursachen zurückführen.

Art der Unterbrechung	Beispiel
Unterschiedliche Namen	Dieselbe Pumpe heißt im SCADA P-101A, im CMMS PUMP_101_A und im ERP trägt sie die Anlagennummer 400123
Fehlende Beziehungen	Die Hierarchie – zu welcher Linie gehört die Anlage – ist vorhanden. Der Fluss – was versorgt sie – und die Abhängigkeit – von welchem Versorgungsmedium hängt sie ab – sind jedoch nirgends dokumentiert
Abweichende Zeiten	Die Uhren von Anlage und Server sowie der Aufzeichnungszeitpunkt unterscheiden sich. Wird eine unterbrochene Verbindung wiederhergestellt, treffen verspätete Daten gesammelt ein
Auseinanderlaufende Kopien	Der Anlagenstamm wurde in jedes System kopiert. Anschließend wurde die Anlage in einem System verschoben, ohne dass die anderen Systeme davon erfuhren

Die vierte Ursache ist besonders tückisch. Anfangs sind die Kopien identisch, sodass kein Problem erkennbar ist. Sobald sie auseinanderlaufen, fehlt jedoch jede Grundlage für die Entscheidung, welche Version korrekt ist.

3. Erster Strang — Identität: eine führende Quelle, alles andere wird abgeleitet

Es gilt ein Grundsatz: Für Stammdaten gibt es genau eine führende Quelle (SSOT), von der alle anderen Darstellungen abgeleitet werden. Abgeleitete Daten lassen sich jederzeit neu erzeugen. Laufen sie auseinander, ist die Entscheidung daher eindeutig: Die führende Quelle hat Vorrang.

In PlantPulse ist der PostgreSQL-Metastore diese führende Quelle. Er enthält Unternehmen · Standorte · Anlagenbaum · Tags · Alarmkonfigurationen · Befehlsdefinitionen. Der im Folgenden beschriebene Graph, die Topic-Pfade und die für die KI sichtbare Struktur werden vollständig aus diesen Daten abgeleitet.

Externe IDs werden über eine «Zuordnungsspalte» eingebunden

Die ID eines anderen Systems darf nicht anstelle der eigenen ID verwendet werden. Beide Systeme erzeugen IDs nach unterschiedlichen Regeln. Stattdessen wird die eigene ID nach den eigenen Regeln vergeben und die ID des Fremdsystems in einer separaten Spalte hinterlegt.

Entität	Eigene ID	ID des Fremdsystems
Kunde	customer_id — nur Buchstaben · Ziffern · _	external_customer_id (MES · ERP)
Produkt	Produkt-ID	Externe Produkt-ID

Ändert das ERP sein Codesystem, bleiben damit alle internen Joins intakt. Nur die Zuordnungsspalte muss angepasst werden.

Auch menschliche Bezeichnungen werden in IDs aufgelöst

«Kompressor der Linie 3» ist keine ID. Es muss einen separaten Schritt geben, der eine von Menschen verwendete Bezeichnung in die ID der führenden Quelle auflöst. Bei einer Anfrage führt PlantPulse AI zuerst genau diesen Schritt aus (search_domains). Ist diese Auflösung falsch, liefert selbst eine ansonsten perfekte Analyse eine präzise Antwort zur falschen Anlage.

4. Zweiter Strang — Beziehungen: Eine Hierarchie allein reicht nicht aus

Die Hierarchie beantwortet die Frage «Wo befindet es sich?»

Die ISA-95-Hierarchie bildet das Gerüst des Threads.

Enterprise ─ Site ─ Area ─ Line ─ Equipment ─ Tag ─ 값

Mit diesem Baum lassen sich Fragen wie «alle Anlagen der Linie 3» oder «OEE-Rollup auf Standortebene» beantworten. Auch die KPI-Rollups von PlantPulse werden entlang dieses Baums nach Linie · Bereich · Standort · Unternehmen aggregiert.

Auch die Messaging-Adressen werden aus diesem Baum abgeleitet. Die UNS(Unified Namespace)-Topics von MQTT verwenden direkt den Hierarchiepfad.

pp/{site_id}/{area_id}/{line_id}/{equipment_id}/{tag_id}/point

Allein anhand des Topic-Namens ist erkennbar, woher ein Wert stammt. Der Kontext wird mitgeliefert, ohne dass der Empfänger ihn separat abfragen muss – der Thread ist damit gewissermaßen in die Nachricht eingebettet.

Wenn die Hierarchie zur Adresse wird, ändert eine Verschiebung in der Hierarchie auch die Adresse

Wird ein Tag einer anderen Anlage zugeordnet, ändert sich sein MQTT-Topic. Externe Systeme, die das alte Topic abonniert haben, empfangen lautlos und ohne Fehlermeldung keine Werte mehr. Vor einer Änderung der Hierarchie muss daher geprüft werden, ob der betreffende Pfad abonniert wird. Aus diesem Grund sollte die Hierarchie anfangs sorgfältig und später nur selten geändert werden. In PlantPulse kann der Topic-Pfad vorab auf der UNS-Seite angezeigt und kopiert werden.

Gerichtete Beziehungen beantworten die Frage «Was wird davon beeinflusst?»

Die Frage «Welche Bereiche stehen still, wenn diese Anlage ausfällt?» lässt sich nicht anhand der Hierarchie beantworten. Anlagen derselben Linie versorgen sich nicht zwangsläufig gegenseitig. Umgekehrt kann ein Luftkompressor in einem anderen Bereich die gesamte Linie zum Stillstand bringen. Deshalb werden zusätzlich zur Hierarchie gerichtete Beziehungen modelliert.

Beziehung	Bedeutung	Ergebnis der Traversierung
FEEDS	Vom vorgelagerten zum nachgelagerten Objekt fließt etwas	Nachgelagert: Reichweite der Stillstandsauswirkung · vorgelagert: mögliche Ursachen einer Qualitätsabweichung
DEPENDS_ON	Das Objekt hängt von Versorgungsmedien wie Strom · Druckluft · Kühlung ab	Welche Anlagen fallen gemeinsam aus, wenn ein Versorgungsmedium ausfällt?
PRODUCES	Das Objekt produziert etwas	Von der Anlage zum Produkt

Auch auf Produktseite wird dieselbe Kette aufgebaut: Produktroute – Reihenfolge der Prozessschritte eines Produkts – → Prozessschritt – Definition des Prozesses und zugeordnete Anlage – → Verbindungsstruktur – Flüsse und Abhängigkeiten zwischen Anlagen. Dass «Produkte, die diesen Prozess verwenden» in der Prozessansicht schreibgeschützt ist, liegt daran, dass dieser Wert aus der Produktroute abgeleitet wird. Würde er an zwei Stellen separat gepflegt, liefen die Kopien auseinander, wie im vierten Fall in Abschnitt 2 beschrieben.

Der Graph ist ein Derivat

Für Abfragen, die Beziehungen traversieren, ist ein Graph besonders geeignet. Wird die Graphdatenbank jedoch als zweite führende Quelle eingerichtet, verletzt dies den Grundsatz aus Abschnitt 3: Der Anlagenstamm existiert dann an zwei Stellen und die Synchronisierungspipeline wird zum schwächsten Glied des Threads.

PlantPulse verfolgt deshalb den umgekehrten Ansatz.

• Der Graph ist ein RDF-In-Memory-Modell innerhalb der Platform (Apache Jena) und wird durch vollständiges Einlesen des Metastores neu aufgebaut. Es gibt keinen synchronisierten Zwischenspeicher
• Ein Neuaufbau erfolgt, wenn bei einer Abfrage die TTL von standardmäßig 10 Minuten abgelaufen ist (semantic.graph.refresh.minutes). Auch bei mehreren gleichzeitigen Abfragen wird das Modell nur einmal neu aufgebaut; alle übrigen Abfragen erhalten das vorherige Modell
• Der Nachteil ist eindeutig: Eine gerade registrierte Anlage ist möglicherweise erst nach der nächsten Aktualisierung im Graph enthalten. Dafür ist es strukturell ausgeschlossen, dass sich der Graph dauerhaft von der führenden Quelle entkoppelt

Bei einem Derivat bedeutet fehlende Aktualität «Verzögerung», nicht «Fehler»

Ist eine synchronisierte Kopie falsch, ist nicht bekannt, wie lange sie falsch bleiben wird. Ein regelmäßig neu aufgebautes Derivat bleibt dagegen höchstens für einen Aktualisierungszyklus falsch. Dieser Unterschied ist beim Entwurf eines Threads entscheidend: Eine Verzögerung löst sich durch Warten, ein Auseinanderlaufen muss dagegen von einem Menschen erkannt und behoben werden.

5. Dritter Strang — Zeit: Der Fertigungsauftrag als Join-Schlüssel

Identität und Beziehungen verbinden das Was mit dem Wo. Fragen in einer Fabrik enthalten jedoch fast immer auch ein Wann – etwa «bei der Fertigung dieses Loses» oder «zwei Wochen vor dem Ausfall».

Der Workorder ist der Join-Schlüssel der Zeitachse

Der Fertigungsauftrag beziehungsweise Workorder nimmt im Thread eine besondere Rolle ein. Jeder Auftrag verweist gleichzeitig auf Anlage · Produkt · Kunde · Verantwortlichen und enthält zusätzlich geplante Start- und Endzeitpunkte sowie die Zielmenge. Ein einzelner Workorder bildet damit direkt folgende Join-Bedingung:

«Die Zeitreihe dieser Anlage in diesem Zeitraum gehört zu diesem Produkt und diesem Kunden.»

Dank dieses Joins kann die OEE pro Workorder berechnet und eine Anlagenansicht auf «nur Workorder dieser Anlage» eingegrenzt werden. Sind dagegen nur Zeitreihen ohne Workorder vorhanden, gibt es zwar viele Werte, aber es bleibt unbekannt, bei der Herstellung welches Produkts diese Werte entstanden sind.

Gespeicherte und abgeleitete Zustände werden getrennt

Sobald Zeit berücksichtigt wird, entstehen zwei Arten von Zuständen.

	Beispiel	Speicherort
Gespeicherter Zustand	Wartend · In Bearbeitung · Pausiert · Abgeschlossen · Fehlerhaft beendet	Datenbank
Abgeleiteter Zustand	Verspätet – geplanter Start überschritten, aber noch nicht gestartet – · Storniert – geplantes Ende überschritten, ohne dass ein Start erfolgt ist	Wird von der Benutzeroberfläche anhand der aktuellen Zeit berechnet – nicht in den Daten vorhanden

Es gibt einen Grund, abgeleitete Zustände nicht zu speichern. Wird «Verspätet» gespeichert, entsteht sofort eine neue Frage: Wer hebt diesen Zustand wann wieder auf? Sobald nur eine Aktualisierung ausbleibt, sind die Daten falsch. Der Nachteil ist, dass sich DELAY weder über die API noch in der DB finden lässt. Wird ein Zustand entlang des Threads an ein externes System übergeben, muss daher auch die Ableitungsregel übermittelt werden.

Ereigniszeit und Ankunftszeit sind nicht identisch

Wenn die Verbindung ausfällt, puffert Edge die Werte lokal und überträgt sie nach der Wiederherstellung gesammelt. Dadurch gehen keine Werte verloren, aber mehrere Stunden alte Werte treffen erst jetzt ein. Für zeitbasierte Joins im Thread muss daher immer die Ereigniszeit (event time) verwendet werden. Bei einem Join anhand der Ankunftszeit würden alte Werte fälschlich dem Workorder unmittelbar nach der Wiederherstellung zugeordnet, während der Workorder aus dem Zeitraum des Verbindungsausfalls leer bliebe.

6. Werte gehören nicht in den Graph — sondern Zeiger

Bei der Abbildung eines Threads als Graph liegt es nahe, auch die Werte der Zeitreihen darin zu speichern. Davon ist abzusehen. Zeitreihen wachsen unbegrenzt und werden typischerweise nur für «einen Tag in einem Zeitraum» gelesen. Sie gehören daher in einen dafür ausgelegten Speicher, also eine Zeitreihendatenbank.

Stattdessen verweist der Tag-Knoten im Graph darauf, wo sich seine Werte befinden und wie sie gelesen werden können.

Eigenschaft	Bedeutung	Beispiel
seriesKey	Abfrageschlüssel der Zeitreihe	Tag-ID
seriesStore	Speicher und Tabelle	Kennung des Zeitreihenspeichers
seriesTool	Mit welchem Werkzeug werden die Daten gelesen?	get_tag_history
lastValue · lastTimestamp	Snapshot des aktuellen Werts	Ermöglicht die Anzeige des aktuellen Zustands ohne zusätzliche Abfrage

seriesTool nimmt dabei eine interessante Position ein. Da der Graph nicht nur auf die Daten, sondern auch auf die «Lesemethode» verweist, kann jeder, der dem Graph gefolgt ist – ein Mensch oder ein KI-Agent –, direkt aus dem Graph ermitteln, welches Werkzeug als Nächstes aufzurufen ist. Die Timeline der Anlage wird auf dieselbe Weise referenziert (timelineKey · timelineStore).

Dies ist zugleich ein allgemeines Prinzip des Threads: Der Thread verschiebt keine Daten, sondern verbindet die Wege zu den Daten.

7. Standards werden an «Systemgrenzen» eingesetzt

Standards wie UNS · Sparkplug B · OPC-UA · AAS(Asset Administration Shell) bilden die gemeinsame Sprache, mit der ein Thread außerhalb des eigenen Systems bereitgestellt wird.

Standard	Was wird standardisiert?	Verwendung in PlantPulse
UNS (MQTT)	Hierarchiepfad als Topic-Adresse	Topics aus der Hierarchie erzeugen und in einer Vorschau anzeigen
Sparkplug B	MQTT-Payload und Status (birth · death)	In Edge aktivierbar und verwendbar, standardmäßig deaktiviert
OPC-UA	Informationsmodell und Zugriff für Anlagen	Treiber · Standardbenutzeroberfläche (:12780)
AAS V3	«Digitales Typenschild» einer Anlage – technische Informationen werden in Submodellen gebündelt	Standardbenutzeroberfläche (:8091)

Der Versuch, einen Standard als internes Modell zu verwenden, ist meist nachteilig. Ein Standard ist der gemeinsame Nenner, auf den sich mehrere Unternehmen verständigt haben. Daher kann er nicht alle Beziehungen einer konkreten Fabrik abbilden, beispielsweise welches Objekt ein anderes versorgt. Zudem würde jede Überarbeitung des Standards auch das interne Modell verändern. Intern die eigene führende Quelle, extern den Standard – eine Übersetzung an der Systemgrenze reduziert Unterbrechungen des Threads.

8. KI ist nur auf einem durchgängigen Thread präzise

Wird ein Sprachmodell gefragt: «Wie läuft der Kompressor der Linie 3 in letzter Zeit?», tut das Modell letztlich nichts anderes, als dem Thread zu folgen.

① 「3라인 압축기」 → 설비 ID          식별
② 이 설비의 상류 · 하류 · 의존          관계 (그래프)
③ 태그 노드의 seriesTool 로 이력 조회   시간 (포인터)
④ 해당 기간의 워크오더 · 알람 · 문서     시간 + 식별

Ist der Thread unterbrochen, füllt das Modell die Lücke mit plausibel klingenden Aussagen. Kann ein Name nicht aufgelöst werden, wählt es möglicherweise eine ähnliche Anlage. Fehlen Beziehungen, vermutet es Auswirkungen allein deshalb, weil sich Objekte in derselben Linie befinden. Die Genauigkeit einer KI für die Fertigung hängt deshalb zunächst stärker von der Vollständigkeit des Threads als von der Größe des Modells ab. Aus demselben Grund zeigt das Werkzeug zur Graphabfrage beim Erreichen der Tiefenbegrenzung truncated an und kennzeichnet eine nicht berechenbare Summe mit total_tag_count_unknown als «unbekannt». Eine Unterbrechung muss ausdrücklich als solche ausgewiesen werden, damit das Modell die Lücke nicht selbst füllt. Die verfügbaren Werkzeuge sind unter Ontologie aufgeführt.

Checkliste für den Entwurf

Beim Aufbau oder bei der Inspektion eines Threads sollten unabhängig vom verwendeten Technologie-Stack folgende Fragen gestellt werden.

Frage	Kennzeichen einer guten Antwort
Wo befindet sich die führende Quelle des Anlagenstamms?	An genau einer Stelle. Alles andere wird daraus abgeleitet und kann neu aufgebaut werden
Wie werden IDs externer Systeme eingebunden?	Die eigene ID bleibt unverändert; externe IDs werden über eine Zuordnungsspalte eingebunden
Gibt es einen Schritt, der menschliche Bezeichnungen in IDs auflöst?	Ja. Dieser Schritt erfolgt vor der Analyse
Gibt es neben der Hierarchie auch gerichtete Beziehungen?	Fluss (FEEDS) · Abhängigkeit (DEPENDS_ON) werden separat modelliert
Ist der Graph die führende Quelle oder ein Derivat?	Ein Derivat. Er wird ohne synchronisierten Zwischenspeicher neu aufgebaut. Die maximale Verzögerung ist bekannt
Werden Zeitreihenwerte in den Graph kopiert?	Nein. Es werden nur Zeiger und Lesemethode hinterlegt
Was wird für zeitbasierte Joins verwendet?	Die Ereigniszeit. Start und Ende des Workorders bilden die Join-Bedingung
Werden abgeleitete Zustände gespeichert?	Nein. Bei der Übergabe an externe Systeme wird auch die Ableitungsregel übermittelt
Was wird durch eine Änderung der Hierarchie beeinträchtigt?	Es ist bekannt, dass sich die Topic-Adresse ändert, und die Abonnenten werden zuerst geprüft
Wo werden Standards eingesetzt?	An der Systemgrenze. Intern gilt die eigene führende Quelle, extern der Standard

Weiterführende Informationen

KI in der Fertigung — was Fabrikdaten vom Modell verlangen · Der Weg eines Werts bis zur Anzeige — von Edge bis zur Anzeige · UNS — aus der Hierarchie erzeugte Topics · Ontologie — Werkzeuge zum Traversieren von Beziehungen · Datenbankmodell — Tabellen der führenden Quelle · Gesamtarchitektur