Kontextmodell: Wie Daten ihren betrieblichen Bedeutungsrahmen erhalten

Was ein Kontextmodell bedeutet

Die grundlegende Forschung zu kontextsensitiven Systemen versteht Kontext als Information, mit der sich die Situation einer relevanten Entität charakterisieren lässt. Eine Entität kann dabei eine Person, ein Ort oder ein Objekt sein, das für die Interaktion zwischen Nutzer und Anwendung bedeutsam ist.^[1] Für betriebliche Prozesse muss diese allgemeine Idee präzisiert werden: Welche Kontextangaben verändern die Bedeutung einer Aufzeichnung oder bestimmen, ob sie in einer konkreten Situation anwendbar ist?

Ein Kontextmodell beantwortet diese Frage strukturell. Es legt fest, welche Arten von Kontext unterschieden werden, wie sie miteinander verbunden sind und für welchen Zeitraum beziehungsweise Geltungsbereich eine Aussage gilt. Damit schafft es eine Grundlage für Process Intelligence: Beobachtete Zusammenhänge können nur dann sinnvoll verglichen und später genutzt werden, wenn erkennbar bleibt, unter welchen Bedingungen sie entstanden sind.

Das Modell selbst ist weder eine Analyse noch eine Entscheidung. Es liefert den Bedeutungsrahmen, innerhalb dessen Daten ausgewertet, Regeln angewendet und Hinweise beurteilt werden können.

Beispiel: Ein Messwert im Chargenprozess

Ein fiktiver Fall: Während derselben Produktionsaufgabe werden zweimal 18,4 °C erfasst. Sensor R misst die Luft im Betriebsraum. Fühler P misst die Temperatur des verarbeiteten Produkts. Zahl, Einheit und Zeitpunkt stimmen überein; die Beobachtungen beantworten dennoch unterschiedliche Fragen.

Für den Raumwert ist der Betriebsraum das beobachtete Objekt. Die Charge gehört zum begleitenden Arbeitskontext. Beim Produktwert ist dagegen das Produkt selbst Gegenstand der Messung. Das Kontextmodell muss diese Bezüge auseinanderhalten und die jeweilige Messstelle sowie das Messverfahren zuordnen.

Eine Prüfung der Produkttemperatur darf den Raumwert nicht allein wegen des passenden Zahlenformats als Ersatz verwenden. Dafür wäre eine eigene, fachlich begründete Ableitung erforderlich. Ebenso folgt aus einer passenden Raumtemperatur nicht, dass die Produkttemperatur im vorgesehenen Bereich liegt.

Für einen späteren Vergleich werden deshalb zunächst Beobachtungen desselben Gegenstands und derselben Eigenschaft ausgewählt. Erst danach lassen sich weitere Bedingungen wie Prozessphase, Messverfahren und geltende Vorgaben vergleichen. Der gleiche Zahlenwert ist kein hinreichendes Ähnlichkeitskriterium.

Gleiche Zahlen sind noch keine vergleichbaren Beobachtungen

Im Beispiel mit 18,4 °C stimmen Zahlenwert, Einheit und Zeitpunkt überein. Trotzdem beantwortet der Raumfühler eine andere Frage als der Produktfühler. Ein zusätzliches Feld „Ort“ beseitigt diesen Unterschied nicht, wenn unklar bleibt, woran gemessen wurde.

Das Kontextmodell muss daher zunächst Gegenstand und Eigenschaft der Beobachtung ausdrücken. Danach kommen für den Zweck relevante Bedingungen hinzu, etwa Prozessphase und Messverfahren. Eine flache Tabelle kann diese Bezüge ebenso ausdrücklich modellieren; entscheidend ist ihre Bedeutung, nicht die Darstellungsform.

Beobachtung, Ergebnis und Bezugsobjekt müssen getrennt bleiben

Bei Mess- und Sensordaten besteht der Kontext nicht nur aus Wert und Zeitstempel. Es muss unterscheidbar sein, welches Merkmal beobachtet wurde, welches Objekt dieses Merkmal besitzt, welches Verfahren oder welcher Sensor eingesetzt wurde und welches Ergebnis daraus hervorging.

Die W3C-Empfehlung SSN/SOSA modelliert dafür unter anderem Beobachtungen, Sensoren, beobachtete Eigenschaften, Untersuchungsobjekte, Verfahren und Ergebnisse.^[3] Diese Trennung verhindert, dass beispielsweise die Temperatur eines Raumes, eines Gerätes und eines Produkts allein wegen eines ähnlichen Zahlenwertes gleich behandelt wird.

Auch manuelle Beobachtungen benötigen einen solchen Bezugsrahmen. Wird der Zustand eines Materials visuell beurteilt, sollte das System zwischen der beobachteten Eigenschaft, der verwendeten Prüfmethode, dem erfassten Ergebnis und der verantwortlichen Person unterscheiden. Erst dadurch kann eine spätere Analyse erkennen, welche Beobachtungen tatsächlich vergleichbar sind.

Beobachteter und abgeleiteter Kontext sind nicht dasselbe

Ein Teil des Kontextes wird unmittelbar erfasst: Eine Person bestätigt eine Aufgabe, ein Gerät liefert einen Messwert oder ein System protokolliert einen Zustandswechsel. Andere Angaben werden abgeleitet. Aus mehreren Signalen kann beispielsweise geschlossen werden, dass eine Anlage in Betrieb war oder eine Prozessphase begonnen hatte.

Das Kontextmodell sollte deshalb kenntlich machen, ob eine Aussage beobachtet, manuell eingegeben, aus Stammdaten übernommen oder durch eine Regel beziehungsweise ein Modell abgeleitet wurde. Für abgeleitete Aussagen gehören auch verwendete Eingaben, Regelversion und Zeitpunkt der Ableitung zum Kontext.

Eine Ableitung ist nicht automatisch falsch oder schwächer. Sie beantwortet jedoch eine andere Evidenzfrage als eine unmittelbare Beobachtung. Wenn beides ununterscheidbar gespeichert wird, kann eine spätere Prüfung nicht mehr erkennen, wo die ursprüngliche Information endet und die Interpretation des Systems beginnt.

Kontext verändert sich mit Zeit und Zustand

Betrieblicher Kontext ist selten statisch. Eine SOP wird ersetzt, eine Person wechselt ihre Rolle, ein Gerät erhält eine neue Kalibrierung und eine Charge geht von „in Bearbeitung“ zu „gesperrt“ oder „freigegeben“ über. Eine aktuelle Stammdatenansicht darf diese früheren Verhältnisse nicht rückwirkend auf historische Vorgänge übertragen.

Das Kontextmodell muss deshalb unterscheiden, wann eine Information erfasst wurde und wann sie galt. Die heute aktive SOP-Version ist nicht zwangsläufig die Version, nach der eine Aufgabe gestern ausgeführt wurde. Ebenso kann ein Material zum Zeitpunkt einer Messung einem anderen Lagerort oder Status zugeordnet gewesen sein als bei einer späteren Auswertung.

Für verlässliche Vergleiche sind daher versionierte Beziehungen erforderlich. Sie halten fest, welcher Kontext zu einem bestimmten Vorgang gehörte, auch wenn sich Rollen, Regeln oder Objekte danach verändern. Ohne diese zeitliche Bindung entsteht ein scheinbar vollständiges, aber historisch falsches Bild.

Versionierte Wissensmodelle halten nachvollziehbar, welche Modellfassung identifiziert, freigegeben und zu welchem Zeitpunkt angewendet wird.

Beziehungen halten den Bedeutungszusammenhang zusammen

Kontext entsteht nicht allein aus Eigenschaften, sondern vor allem aus Beziehungen. Eine Person führt eine Aufgabe aus. Eine Aufgabe verwendet ein Material. Ein Messvorgang beobachtet eine Eigenschaft einer Probe. Ein Ergebnis wird anhand einer bestimmten Spezifikation geprüft. Eine Freigabe bezieht sich auf einen konkreten Produktzustand.

W3C PROV stellt für Herkunftszusammenhänge unter anderem Entitäten, Aktivitäten und Agenten sowie deren Nutzung, Erzeugung und Verantwortungsbezüge bereit. Das Modell ist domänenunabhängig und ausdrücklich erweiterbar, sodass anwendungsspezifische Informationen ergänzt werden können.^[2]

Ein Kontextmodell kann solche allgemeinen Beziehungsmuster übernehmen und um betriebliche Begriffe erweitern. Dann bleibt beispielsweise erkennbar, dass eine Aufgabe ein bestimmtes Material verbrauchte, einen neuen Chargenzustand erzeugte und von einer berechtigten Person nach einer geltenden Arbeitsanweisung ausgeführt wurde.

Data Provenance betrachtet dabei vor allem Herkunft, Entstehung und Veränderung einer Information. Hier steht dagegen der situative Geltungsrahmen einer Information im Vordergrund. Die Fragestellungen können sich überschneiden; daraus folgt keine allgemeine Rangordnung zwischen Kontextmodell und Provenance.

Welche Dimensionen ein betrieblicher Kontext benötigt

Der erforderliche Kontext hängt von der jeweiligen Frage ab. Für regulierte Produkt- und Chargenprozesse sind typischerweise mehrere Dimensionen relevant:

• Objektkontext: Charge, Material, Produkt, Probe, Dokument, Gerät oder Ressource, auf die sich eine Information bezieht.
• Prozesskontext: Aufgabe, Prozessphase, vorangegangene Handlung, Ergebnis und nachfolgender Übergang.
• Personen- und Rollenkontext: ausführende, prüfende oder freigebende Identität sowie die dabei ausgeübte Rolle.
• Zeitkontext: Erfassungszeitpunkt, Gültigkeitszeitraum, Reihenfolge und gegebenenfalls Beginn und Ende einer Tätigkeit.
• Orts- und Systemkontext: Betriebsbereich, Anlage, Gerät, Anwendung oder Schnittstelle, in der die Information entstand.
• Regelkontext: geltende SOP-Version, Spezifikation, Berechtigung, Prüfregel oder Freigabeanforderung.
• Bedingungskontext: Temperatur, Luftfeuchte, Energieverbrauch, Materialeigenschaft oder andere relevante Rahmenbedingung.
• Bewertungskontext: Prüfung, Abweichung, Nacharbeit, Begründung und fachliche Entscheidung.

Nicht jede Aufzeichnung benötigt jede Dimension. Ein gutes Kontextmodell erzwingt deshalb keine maximale Datensammlung. Es bestimmt, welche Zusammenhänge für einen konkreten Zweck erforderlich sind und welche optional bleiben.

Den Kontext an der beabsichtigten Verwendung prüfen

Für eine Produktbewertung genügt es im Beispiel nicht, irgendeinen Temperaturwert zu besitzen. Die Prüfung muss fragen, ob er zum vorgesehenen Messgegenstand und Verfahren gehört. Fehlt dieser Bezug, sollte die Anwendung die Unsicherheit kenntlich machen, statt den Raumwert still als Ersatz zu verwenden.

Strukturregeln können erforderliche Beziehungen prüfen, etwa mit SHACL.[5] Ob die ausgewählten Kontextangaben für die fachliche Verwendung genügen, ist gesondert zu bewerten. Nicht benötigte Angaben erhöhen den Erfassungsaufwand, ohne diese konkrete Lücke zu schließen.

Vom Schlüssel-Wert-Paar bis zum semantischen Modell

Kontext lässt sich auf unterschiedliche Weise repräsentieren. Einfache Schlüssel-Wert-Paare eignen sich für überschaubare Angaben wie „Raum = Produktion 2“. Hierarchische Strukturen können verschachtelte Zusammenhänge abbilden. Relationale Datenmodelle ordnen Informationen über Tabellen und Schlüssel. Graphmodelle stellen Objekte und ihre Beziehungen unmittelbar in den Mittelpunkt.

Knowledge Graphs eignen sich, wenn konkrete Objekte, Ereignisse, Personen und Bedingungen über viele Beziehungstypen hinweg verbunden und abgefragt werden sollen. Der Graph ist jedoch nicht mit dem Kontextmodell gleichzusetzen: Er ist eine mögliche Repräsentationsform, während das Kontextmodell festlegt, welche situativen Zusammenhänge fachlich bedeutsam sind.

Ontologien können Begriffe, Klassen und Beziehungen formal definieren. OWL 2 stellt dafür Klassen, Eigenschaften, Individuen und logisch definierte Bedeutungen bereit.^[4] Nicht jedes Kontextmodell muss eine Ontologie sein. Für gemeinsame Semantik und maschinelle Schlussfolgerungen kann eine ontologische Ausgestaltung jedoch sinnvoll werden.

Beschreibung und Nutzung der Situation bleiben unterscheidbar

Die zuvor beschriebenen Tabellen-, Graph- oder Ontologieformen beantworten die Frage nach der Repräsentation. Das Kontextmodell bestimmt dagegen, welche situativen Unterschiede relevant sind. Seine spätere Nutzung muss festlegen, wie auf einen passenden, fehlenden oder widersprüchlichen Kontext reagiert wird.

Im Temperaturfall beschreibt das Modell den Messgegenstand. Ob ein fehlender Produktwert eine Rückfrage, eine zusätzliche Messung oder eine Unterbrechung auslöst, ist eine gesonderte Anwendungsentscheidung.

Kontext begrenzt, wann Wissen anwendbar ist

Ein betriebliches Erkenntnismodell sollte nicht nur speichern, dass eine Maßnahme in der Vergangenheit mit einem guten Ergebnis verbunden war. Es muss auch festhalten, unter welchen Bedingungen diese Erfahrung gewonnen wurde und für welche Situationen sie geprüft ist.

Operative Wissensmodelle nutzen diesen Geltungskontext, um Wissen mit konkreten Aufgaben, Zuständen und Entscheidungen zu verbinden. Das Kontextmodell liefert dafür die beschreibende Grundlage. Das operative Wissensmodell ergänzt Regeln der Nutzung, Freigabe und Anwendung.

So lässt sich vermeiden, dass eine Erfahrung aus Produkt A ungeprüft auf Produkt B übertragen oder eine Aussage aus einer bestimmten Anlagenkonfiguration als allgemeingültig behandelt wird. Kontext macht Wissen nicht automatisch richtig. Er macht seine Reichweite nachvollziehbar.

Was ein Kontextmodell nicht leistet

• Es erfasst nicht automatisch jeden relevanten Einfluss. Nicht modellierte Bedingungen bleiben unsichtbar.
• Es beweist keine sachliche Richtigkeit. Eine formal vollständige Kontextangabe kann inhaltlich falsch sein.
• Es rechtfertigt keine unbegrenzte Datensammlung. Erfassungsumfang, Zweck, Berechtigung und Aufbewahrung müssen angemessen festgelegt werden.
• Es bleibt pflegebedürftig. Neue Prozessvarianten, Regeln und Objektarten können Erweiterungen des Modells erfordern.

Der Vergleich beginnt beim Gegenstand der Beobachtung

Die beiden Werte von 18,4 °C sind nicht austauschbar. Erst die Frage nach Messgegenstand und Eigenschaft entscheidet, ob sie für eine bestimmte Auswertung zusammen betrachtet werden dürfen. Weitere Bedingungen können diesen Vergleich zusätzlich begrenzen.

Ein gutes Kontextmodell erhält genau die Unterscheidungen, die solche Entscheidungen begründen. Es macht auch kenntlich, wenn Angaben fehlen oder nur abgeleitet wurden. Dadurch bleibt die Reichweite einer Beobachtung sichtbar.