Let’s break it down. Vom Standard zur Praxis. Der Aufbau eines konzeptuellen Datenmodelles.

In den vergangenen Beiträgen haben wir uns gefragt, wie das wertvolle Erfahrungswissen von Expert:innen in Unternehmen dauerhaft gesichert werden kann und Ontologien als konzeptuelle Datenmodelle als vielversprechende Methode vorgestellt. Im letzten Beitrag sind wir auf die Detaillierungsebenen eingegangen: von den abstrakten Top-Level-Ontologien wie der Basic Formal Ontology (BFO) über domänenspezifische Referenzontologien wie die Industrial Ontology Foundry Core (IOF Core) bis hin zur anwendungsspezifischen Ebene.

Doch was bedeutet das nun konkret zum Beispiel für einen Montageprozess in der Produktion? Genau das schauen wir uns heute an.

Woher soll man wissen, was man machen soll, wenn man nicht gefragt hat?

Wer eine Ontologie baut, ohne vorher zu wissen, was sie leisten soll, baut ein Haus ohne Grundriss. Bevor man also die Pyramide von oben nach unten durcharbeitet und sich an die Entwicklung einer Anwendungsontologie macht, müssen zunächst die richtigen Fragen gestellt werden, die sogenannten Kompetenzfragen nach T. Gruber.

Mit diesen Fragen legt man fest, welche Informationen das Modell am Ende liefern soll. Und sie zwingen dazu, sich auf das Wesentliche zu konzentrieren. Denn eine Ontologie, die alles abbilden will, bildet am Ende nichts richtig ab.

Für unseren Montageprozess könnten solche Kompetenzfragen lauten:

• Wo bestehen Abhängigkeiten im Montageprozess und welche Schritte könnten also parallel ausgeführt werden?
• Welche Montageschritte und Qualifikationen sind zur Montage einer Komponente in welcher Reihenfolge erforderlich?
• An welchen Prozessschritten treten die meisten Fehler auf oder Fehler eines bestimmten Typs?

Von der Pyramide zur Praxis: Klassen werden konkret

Erinnern wir uns an die Pyramide: Ganz oben thront die BFO mit allgemeinen Konzepten wie “material entity” oder “process”. Eine Ebene tiefer präzisiert die IOF Core diese Begriffe für den industriellen Kontext. Aus “material entity” werden etwa “Material Product”, “Raw Material” oder “Agent”. Aber selbst “Agent” ist für den Montagebereich noch zu unspezifisch.

Hier kommt die Anwendungsontologie ins Spiel. In ihr spezialisieren wir die abstrakten Klassen Schritt für Schritt. Zunächst legen wir das Grundgerüst fest, also welche Typen von Personen und Prozessen wir überhaupt abbilden wollen:

Man konkretisiert also lediglich die abstrakteren Klassen der übergeordneten Modellebenen, ohne das bestehende Fundament zu verändern. Anschließend kann man die konkreten Instanzen mit all ihren Eigenschaften und Beziehungen modellieren:

Genauso verhält es sich mit weiteren Prozessschritten. Aus dem abstrakten “Planned Process” in der IOF Core werden in der Anwendungsontologie konkrete Schritte wie “Kabelbaum verlegen”, “Schraubenverbindung herstellen” oder “Sichtprüfung durchführen”.

Und schließlich die Modellierung auf Instanzebene

Schauen wir uns an, wie das Modell im Einsatz aussieht. Wir haben drei Montageschritte, die über eine Vorrangbeziehung (und damit transitiv, wie im letzten Beitrag beschrieben) miteinander verbunden sind:

• Schritt A: Grundrahmen montieren – Qualifikation “Mechanik Grundstufe”
• Schritt B: Kabelbaum verlegen – Qualifikation “Elektrotechnik”
• Schritt C: Sichtprüfung und Freigabe – Qualifikation “Qualitätssicherung”

In der Ontologie lässt sich das folgendermaßen darstellen:

Stellen wir dem Modell nun eine Frage: “Welche Prozessschritte können durchgehend von einer Person mit einer bestimmten Qualifikation ausgeführt werden?”

Das Modell schlussfolgert aus der transitiven Relation :hatVorgaenger folgenden Zusammenhang ProzessA → ProzessB → ProzessC. Damit ist auch bekannt, welche Qualifikationen zu welchem Zeitpunkt gefragt sind, und ob eine Person mehrere aufeinanderfolgende Schritte übernehmen kann oder nicht.

Aber das Modell kann noch mehr. Denn Montageprozesse sind selten so linear, wie sie auf den ersten Blick wirken. Nehmen wir ein Beispiel aus der Automobilproduktion: Bevor ein Kabelbaum im Fahrzeug verbaut werden kann, durchläuft er selbst mehrere Vorbereitungsschritte – Drähte werden maschinell auf Länge geschnitten, dann abisoliert und mit Steckverbindern versehen, anschließend zu Kabelbündeln zusammengefasst und schließlich auf einem Formbrett zum fertigen Leitungssatz konfektioniert. Ganz ähnlich verhält es sich mit dem Grundrahmen: Auch hier entsteht das Endprodukt nicht in einem Schritt, sondern über mehrere Zwischenstufen – Einzelteile werden gefügt, verschraubt, auf Maßhaltigkeit geprüft, bevor der Rahmen für den nächsten Montageschritt bereit ist.

Beide Stränge – Kabelbaum und Grundrahmen – sind voneinander unabhängig. Und genau das lässt sich im Modell abbilden. Eine einfache Abfrage genügt, um zu zeigen: Die Vorbereitungsschritte beider Komponenten können parallel laufen. Kein langer Abstimmungsaufwand, keine implizite Erfahrung nötig – das Wissen steckt im Modell.

Und was die dritte Kompetenzfrage betrifft, wo im Prozess entstehen die meisten Fehler, lässt sich auch das ontologisch fassen. Fehlerereignisse werden als eigene Klasse modelliert und direkt mit dem Prozessschritt verknüpft, bei dem sie auftreten:

Wissen wächst mit.

Produktionsprozesse verändern sich, Qualifikationsanforderungen passen sich an, Arbeitsschritte werden umstrukturiert. Was passiert dann?

Ein neuer Montageschritt, eine neue Qualifikationsanforderung, ein neues Werkzeug. All das lässt sich ergänzen, ohne das gesamte Modell umzubauen. Die vorhandenen Strukturen bleiben bestehen und neue Konzepte und Instanzen werden ergänzt. Es ist wie mit einem erfahrenen Kollegen, der dazulernt. Das, was er schon weiß, bleibt. Das Neue kommt obendrauf.

In den nächsten Beiträgen stelle ich euch ein paar bestehende Referenz- und Domänenontologien vor, denn das Rad muss nicht immer neu erfunden werden.

Headerbild: © KI-generiert mit Adobe Firefly
Autorin: Manja Mai-Ly Pfaff-Kastner