XES und OCEL: Zwei Modelle für strukturierte Prozessereignisse

Zwei Darstellungen für Ereignisse und ihre Bezüge

Die Standards XES und OCEL 2.0 setzen unterschiedliche Schwerpunkte beim Austausch von Ereignisdaten.[1][3]

Die passende Darstellung richtet sich danach, welche Beziehungen beim Export erhalten bleiben müssen. Auch ein komplexer Prozess kann mit einer geeigneten XES-Fallsicht untersucht werden. Umgekehrt macht ein OCEL-Export fehlende Objektbezüge nicht nachträglich verfügbar.

XES und OCEL im direkten Vergleich

Die Tabelle ist keine Rangfolge. XES ist nicht allein deshalb ungeeignet, weil ein Prozess mehrere Objekte kennt. Häufig genügt eine sinnvoll gewählte Fallperspektive. Umgekehrt ist OCEL nicht automatisch die bessere Wahl, wenn Beziehungen technisch vorhanden sind, für die Analyse aber keine Rolle spielen.

Entscheidend ist die Frage, welche Information beim Übergang in das Ereignismodell erhalten bleiben muss. Wenn eine Analyse ausschließlich den Lebenszyklus eines Auftrags betrachtet, kann XES präzise und effizient sein. Wenn dieselben Ereignisse gleichzeitig Material, Charge, Anlage, Probe und Auftrag betreffen, bewahrt OCEL diese Mehrfachbezüge expliziter.

Derselbe Vorgang in zwei Exportansichten

In einem fiktiven Beispiel verwendet Aufgabe A-17 die Materialchargen M-01 und M-02 für Zwischenproduktcharge Z-07. Ereignis E-10 dokumentiert diese Materialverwendung. Später verbindet E-11 die Probenentnahme mit Probe P-03 und Z-07. Die Bezeichner sind nur Beispielkennungen.

Eine XES-Sicht mit Z-07 als Fall nimmt E-10 und E-11 in dessen Trace auf. Die zugehörigen Material- und Probenkennungen können als Attribute mitgegeben werden. Soll zusätzlich jeder Materiallebenszyklus als Trace erscheinen, muss entschieden werden, wie E-10 den beiden Materialfällen zugeordnet wird. Seine ursprüngliche Identität sollte für eine Zählung realer Vorgänge erhalten bleiben.

Eine OCEL-Sicht kann E-10 mit A-17, M-01, M-02 und Z-07 sowie E-11 mit P-03 und Z-07 verbinden. Qualifier kennzeichnen die Rolle der Objekte. Ob die konkrete Exportdatei diese Zuordnung tatsächlich enthält, muss geprüft werden; die Möglichkeit des Formats reicht als Nachweis nicht aus.

XES: Eine festgelegte Fallsicht übertragen

Ein XES-Log enthält Traces, die wiederum Ereignisse enthalten. Attribute können auf Log-, Trace- und Ereignisebene zusätzliche Angaben tragen. Die Wahl der Fallidentität bestimmt, welche Ereignisse zu einer Spur zusammengefasst werden.^[2]

Für den Lebenszyklus einer Zwischenproduktcharge kann diese Charge den Trace bilden. Material- und Probenkennungen lassen sich zusätzlich als Attribute übertragen. Wird dagegen der Weg einer Materialcharge über mehrere Produktionsaufgaben untersucht, ist eine andere Fallsicht erforderlich.

Die Fallsicht ist eine nützliche Vereinfachung, wenn sie die konkrete Frage trägt. Bei gemeinsam beteiligten Objekten braucht der Export ausdrückliche Zuordnungs- und Zählregeln. Erweiterungen und eigene Attribute können Informationen ergänzen, ersetzen aber keine gemeinsame Definition ihrer Bedeutung.

Das objektzentrierte Modell von OCEL 2.0

OCEL 2.0 organisiert die Daten nicht primär als Sammlung voneinander getrennter Traces. Das Modell unterscheidet typisierte Ereignisse und typisierte Objekte. Jedes Ereignis besitzt eine eindeutige Kennung, genau einen Ereignistyp, einen Zeitstempel und gegebenenfalls Attribute. Objekte besitzen ebenfalls eindeutige Kennungen, Typen und Attribute.^[3]

Der entscheidende Unterschied liegt in den Beziehungen. Event-to-Object-Beziehungen verbinden ein Ereignis mit beliebig vielen beteiligten Objekten. Ein Ereignis Prüfung freigegeben kann dadurch gleichzeitig mit der Prüfung, der Probe, der Charge und der freigebenden Rolle verbunden sein. Qualifier können ausdrücken, welche Funktion ein Objekt in der konkreten Beziehung erfüllt.

Object-to-Object-Beziehungen halten zusätzlich Zusammenhänge fest, die nicht erst durch ein einzelnes Ereignis entstehen. Eine Probe stammt aus einer Charge, ein Auftrag umfasst mehrere Positionen oder eine Teilcharge gehört zu einer übergeordneten Charge. Auch diese Beziehungen können qualifiziert werden. Sie tragen in OCEL 2.0 jedoch keinen eigenen Zeitstempel und kein Gültigkeitsintervall. Zeitliche Änderungen solcher Beziehungen benötigen eine zusätzliche Modellierungsvereinbarung, beispielsweise über Ereignisse, die den Wechsel beschreiben.

OCEL 2.0 kann außerdem zeitabhängige Objektattribute abbilden. Ein Objektwert muss damit nicht für den gesamten Lebenszyklus als unveränderliche Eigenschaft behandelt werden. Das ist hilfreich, wenn sich beispielsweise Status, Zuordnung oder fachliche Klassifikation nachvollziehbar ändern.

Die Spezifikation beschreibt drei Austauschformen: eine relationale Umsetzung auf Basis von SQLite, XML und JSON. Alle drei sollen dasselbe Metamodell transportieren; die konkrete technische Form kann an Datenhaltung und Werkzeugkette angepasst werden.^[3]

Die Projektion braucht eine dokumentierte Auswahlregel

Für den Exportfall sind die Entscheidungen festzuhalten: Welche Kennung bildet einen Trace, welche Ereignisse werden ausgewählt, welche ursprünglichen IDs bleiben erhalten und wie werden Mehrfachbezüge behandelt? Diese Angaben machen einen erneuten Export und den Vergleich zweier Dateien nachvollziehbar.

Auch bei OCEL bleibt der Umfang eine Auswahl. Werden etwa Geräteobjekte weggelassen, kann der Export später keine gerätebezogene Frage beantworten. Ausdrücklich modellierte Mehrfachbezüge erlauben zusätzliche Sichten, heben die Begrenzung des gelieferten Datenausschnitts aber nicht auf.

Konvertierung ist nicht automatisch verlustfrei

Ein OCEL lässt sich nicht ohne weitere Entscheidung in genau ein fallbezogenes XES-Log überführen. Für die Transformation muss mindestens eine Fallvorstellung gewählt werden. Werden mehrere Objekttypen als Fälle exportiert, können Ereignisse in mehreren Traces auftreten. Beziehungen und Qualifier, die in OCEL eigenständig modelliert sind, benötigen zusätzliche Abbildungsregeln.

Auch der umgekehrte Weg hat Grenzen. Ein XES-Log enthält zwar Ereignisse, Traces und Attribute, aber nicht zwingend die ursprünglichen Objektidentitäten und Beziehungen. Fehlen diese Informationen, können sie durch eine Konvertierung nicht verlässlich rekonstruiert werden. Ein Attribut mit einer Materialnummer beweist beispielsweise noch nicht, welche Rolle dieses Material im Ereignis hatte oder wie es mit anderen Objekten verbunden war.

Darum sollte die Wahl des Austauschmodells möglichst vor der Extraktion geklärt werden. Transformationsregeln, Fallbildung, Datentypen und Umgang mit Mehrfachbezügen gehören zur dokumentierten Datenpipeline. Erst dann bleibt nachvollziehbar, welche fachliche Realität im Log erhalten wurde und welche Perspektive bewusst vereinfacht ist.

Wie eine Exportentscheidung die Analyse beeinflusst

Erscheint E-10 in zwei Materialtraces, kann eine naive Zeilenzählung daraus zwei Verwendungen machen. Eine Auswertung mit Bezug auf die ursprüngliche Ereignisidentität kann diese Mehrfachdarstellung berücksichtigen. Welche Zählweise angemessen ist, richtet sich nach der Frage.

Object-Centric Process Mining untersucht verflochtene Objektlebenszyklen. Conformance Checking vergleicht aufgezeichnetes Verhalten mit einem Modell. Das Austauschformat liefert die Datendarstellung; Methode, Mapping und Bewertungsumfang müssen zusätzlich festgelegt werden.

Datenqualität entsteht vor dem Export

Ein valides Dateiformat garantiert weder vollständige noch richtige Ereignisdaten. XES und OCEL können definieren, wie Werte strukturiert werden. Sie können nicht prüfen, ob eine Tätigkeit tatsächlich erfasst wurde, ob ein Zeitstempel den fachlich richtigen Moment bezeichnet oder ob eine Objektbeziehung aus der realen Ausführung stammt.

Auch die Semantik von Ereignistypen muss außerhalb der Syntax beherrscht werden. Prüfung abgeschlossen kann in einem System die technische Messung, in einem anderen bereits die fachliche Bewertung meinen. Einheitliche Namen helfen nur, wenn Definition, Auslöser und erforderlicher Kontext ebenfalls übereinstimmen.

Für belastbare Analysen braucht es daher kontrollierte Erzeugung, stabile Identitäten, nachvollziehbare Transformationen und Qualitätsprüfungen. Der Standard ist ein Transport- und Strukturvertrag. Die Verlässlichkeit seines Inhalts entsteht im ausführenden System und entlang der gesamten Datenverarbeitung.

OCEL macht ein Modell nicht automatisch fachlich vollständig. Ungeeignete Objekttypen, unklare Qualifier oder fehlende Beziehungen bleiben Modellierungsfehler.

Ein Export muss seine Vereinfachung erkennen lassen

Im Beispiel lässt sich der Chargenverlauf gut als Trace lesen. Die Materialperspektive stellt andere Anforderungen an Zuordnung und Zählung. Beide Darstellungen können sinnvoll sein, wenn ihr Zweck und ihre Ableitung bekannt sind.

Eine brauchbare Übergabe umfasst deshalb mehr als eine lesbare Datei: Sie beschreibt die ausgewählten Objekte, erhaltenen Identitäten und bewusst vereinfachten Beziehungen. Damit kann der Empfänger beurteilen, welche Auswertung der gelieferte Ausschnitt trägt.

Ein Event Log ist kein Audit Trail. Zwecke, Inhalte und regulatorische Anforderungen müssen getrennt beurteilt werden. Keiner der Standards belegt Compliance. Die Einhaltung konkreter Vorgaben ergibt sich aus System, Verfahren, Nutzung und nachweisbarer Kontrolle.