In diesem Artikel zeigen wir am Beispiel eines Herstellers, wie mit unternehmensweiter Terminologie und Produkthierarchien ein Wissensgraph erzeugt werden kann. Dieser ermöglicht intelligente Informationsabfragen und verwendet dazu iiRDS (intelligent information Request and Delivery Standard). Wir führen durch den Proof-of-Concept und zeigen auf, wie zielgerichtet iiRDS angewendet werden kann.
Das ist die Ausgangslage
Ein internationaler Hersteller von Maschinen und Werkzeugen für die Bergbauindustrie möchte seinen Kunden ein hardwareunabhängiges Content-Delivery-Portal zur Verfügung zu stellen. Mit dieser Plattform soll die Auslastung und Produktivität der Maschinen überwacht und verbessert werden. Zu den Produkten des Herstellers zählt ein so genannter Bolter Miner, eine Bergbaumaschine für den Abbau von Kohle und anderen Materialien (Abb. 01).
Abb. 01 Ein Bolter Miner wird zum Beispiel für den Kohleabbau eingesetzt. [1] Quelle Stefan Dötsch, Sandvik
Neben Lifecycle-Daten der Maschine soll auch die Technische Dokumentation auf der Plattform bereitstehen, damit das Personal zielgerichtet auf Anforderungen der Maschine reagieren kann. Das Unternehmen erstellt schon seit Jahren seine Technische Dokumentation mit einem DITA-basierten Redaktionssystem. Sehen wir uns weitere Fakten zur aktuellen Dokumentation an:
- Bis jetzt wird die Technische Dokumentation vorwiegend als PDF publiziert. Dabei können einzelne Dokumente, etwa das Betriebs- und Wartungshandbuch, über 1.200 Seiten umfassen.
- Zulieferdokumentation wird eingearbeitet, wie es notwendig ist. Die Dokumentation wird beigegeben, und in Handbüchern wird bei Bedarf darauf verwiesen.
- Die Handbücher enthalten ein Sicherheitskapitel, in dem auf alle Risiken und Vermeidungen beim Arbeiten an bzw. mit der Maschine hingewiesen wird. Dazu zählen etwa Arbeiten am Hydrauliksystem sowie alle dazugehörigen Warnhinweise.
- Das Troubleshooting wird in einzelnen Tabellen thematisch aufgearbeitet, damit der Servicetechniker sich sofort visuell zurechtfinden kann.
- Ganz oben steht für den Hersteller die Sicherheit, die mit dem Leitsatz „Safety First“ international überschrieben ist.
Szenario „Hydrauliksystem“
Wie schon erwähnt, handelt es sich bei der Maschine, die für den Proof-of-Concept untersucht wird, um eine Bergbaumaschine für Untertage. Ein zentraler Bestandteil der Maschine ist das Hydrauliksystem.
Die Fehlersuche am Hydrauliksystem ist komplex, da für die Bestimmung der Ursachen von Fehlern ganz unterschiedliche Aspekte verantwortlich sein können. Arbeiten am Hydrauliksystem sind gefährlich, wenn nicht sogar lebensbedrohlich, sollten nicht alle notwendigen Sicherheitsmaßnahmen eingehalten werden. Schadhafte, brüchige Stellen wie Leckagen in Hydraulikschläuchen lassen Hochdruck-Hydrauliköl entweichen, das mit dem freien Auge nicht sichtbar ist. Hier kommt es immer wieder zu schweren Verletzungen. Deshalb ist es unerlässlich, bei Arbeiten am Hydrauliksystem auf Gefahren wie diese hinzuweisen.
Die genauen Vorgaben
Als Anwendungsfall (Use Case) für den Proof-of-Concept wurden folgende Vorgaben gewählt:
- Die Informationen sollen mit wenigen Klicks verfügbar sein.
- Die Informationen sollen zu dem gesuchten Kontext passen.
- Die gefundenen Informationen sollen den Usern helfen, die Aufgaben, die sie haben, lösen zu können.
Dabei sind im Detail noch die folgenden Ziele zu verfolgen:
- zielgerichtete Suche nach Keywords, Fragen sowie Fehlerbeschreibungen und -codes
- Troubleshooting soll eine zielgerichtete Anleitung zur Fehlersuche und -behebung geben.
- Sicherheit muss immer zu 100 Prozent gewährleistet werden.
Dazu gibt es auch noch unterschiedliche Rollen der User, die Tabelle 01 zeigt.
Nicht jeder darf alles tun. Damit wird der Content auch entsprechend auf Rollen gefiltert. Wenn der Inhalt hinsichtlich Rollen gefiltert wird, muss dieser auch entsprechend der Verwendung gefunden werden.
Im nächsten Schritt haben wir gemeinsam mit dem Hersteller zwei Szenarien entwickelt, die Tabelle 02 darstellt.
Sehen wir uns als Nächstes die beiden Use Cases genauer an.
Tab. 01 (links) [1] und Tab. 02 [2] rechts.
Johanna und Johann
Das Szenario des ersten Use Case: Johanna arbeitet unter Tage und ist darauf spezialisiert, Hydrauliksysteme zu warten. Johanna hat die Aufgabe, den hydraulischen Druck zu prüfen. Hierfür möchte sie sich vorab informieren, da die Maschine ein neues Modell ist und die Schulung schon vor einiger Zeit stattgefunden hat.
Das Szenario des zweiten Use Case: Johann arbeitet ebenfalls unter Tage. Seine Spezialisierung ist, Störungen am Hydrauliksystem von Abbaumaschinen zu beheben und Wartungsarbeiten durchzuführen. Johann hat die Aufgabe bekommen, folgenden Fehler, der auf dem Display (Abb. 02) angezeigt wird, zu beheben: Interlock: „Hydraulic oil level trip“.
Johann möchte sich vorab informieren, da die Maschine diesen Fehler noch nie hatte.
Jetzt stellt sich die Frage, wie die Inhalte im Redaktionssystem des Herstellers vorliegen. Außerdem, welche Daten im Unternehmen bereits vorhanden sind.
Strukturierter Content mit DITA
Der Content liegt im Redaktionssystem als DITA-Topics vor. Das heißt, der Content ist bereits in Concepts, Tasks und References strukturiert. In den DITA-Topics sind keine Metadaten vergeben, die für das Abrufen des Contents relevant sind. Die Metadaten sind vorrangig für das Verwalten der Topics und für die Wiederverwendung gedacht.
Welche Daten sind noch vorhanden? Der Hersteller hat eine Unternehmensterminologie. Sie wird in einer Terminologiedatenbank verwaltet. Produkthierarchien ergeben sich aus den Baugruppen der Stücklisten.
Im nächsten Schritt haben wir die Terminologie und die Produkthierarchien in einer Unternehmenstaxonomie abgebildet. Der Hersteller hat hier viele Daten in unterschiedlichen Systemen, die konzernweit standardisiert sind. Dies ist eine gute Quelle für unseren Use Case. Allerdings liegen die Daten in unterschiedlichen Quellsystemen und sind deshalb nicht miteinander verknüpft.
Von der Terminologie zur Taxonomie
Durch die Umwandlung der Terminologie in eine Taxonomie entstand die Produkttaxonomie mit den Termen aus der Termdatenbank (Abb. 03).
Dies klingt nach viel Arbeit. Da aber Bolter Miner üblicherweise eine ähnliche Produktstruktur aufweisen, ist dies strukturell trotz Varianten keine Hexerei.
Abb. 02 (l.) Mit diesem Fehler hat es Johann zu tun "Interlock: - Hydraulic-System - Hydraulic oil level trip". [2] und Abb. 03 (r.) Erzeugen der Produkttaxonomie. [2]
Betrachten wir das PI-Class Modell (Produkt-Information) von Prof. Dr. Wolfgang Ziegler und nehmen es als Referenz, dann brauchen wir zusätzlich zu der Produktstruktur eine Informationsstruktur. [3] Wollen wir nun den Usern die passenden Informationen für unseren Use Case zur Verfügung stellen, müssen wir die Informationen zunächst im bisherigen PDF finden. Hier konnten wir Folgendes beobachten: Zu Arbeiten an der Hydraulik, eine potenziell sehr gefährliche Tätigkeit, sind die Informationen über mehrere Seiten verstreut und damit in mehreren DITA-Topics zu finden (Abb. 04).
Wie erreichen wir nun eine konsistente Information, um ein technisches Problem zu lösen? Nicht zuletzt der Fachkräftemangel und damit fehlendes Wissen trägt dazu bei, dass Informationen zur Fehlerbeseitigung konsistent und leicht auffindbar abgelegt sein müssen.
Klar ist, dass wir die Informationen semantisch mit den Produktteilen verknüpfen und gleichzeitig die DITA-Topics semantisch mit standardisierten Metadaten auszeichnen müssen. Genau das unterstützt der intelligent information Request and Delivery Standard (iiRDS). [4]
Abb. 04 Eine Beispielinformation auf dem Weg zur Lösung des Hydraulikproblems; sie ist wie weitere Informationen im Handbuch verteilt. Quelle Helmut Nagy, Martina Schmidt und Harald Stadlbauer.
Zugreifen und verknüpfen
Bei iiRDS handelt es sich um ein semantisches Metadaten-Schema. Es ist standardisiert unter IEC PAS 63485:2023 und damit ein internationaler Standard.
Was ist der Vorteil des Standards? Zuerst muss gesagt werden, dass es der einzige Standard ist, der dem PI-Class Modell folgt. So ist es möglich, die Technische Dokumentation als Dokument, als Topic oder sogar als Fragment mit einer Produkttaxonomie zu verknüpfen. Auch die Verknüpfung mit externen Ereignissen (so genannte „Events“) ist möglich, so dass etwa Fehlercodes oder Sensordaten den richtigen, fokussierten Teil der Technischen Dokumentation holen und einem Servicetechniker darstellen können. Für unsere Zielsetzung ist iiRDS genau das richtige Schema. Ausgehend von unserem Use Case müssen wir die nötigen iiRDS-Metadaten auswählen.
Zum Zeitpunkt des Proof-of-Concept gab es das DITA OT iiRDS-Plug-in noch nicht. [5] Dieses Plug-in kann Metadaten, etwa administrative und funktionale Metadaten (wie Role und Skill-Level), aus DITA-Topics und DITA-Maps extrahieren, sofern diese angegeben sind. Doch auch ohne iiRDS-Plug-in ergeben sich einige dieser Metadaten bereits aus der Natur der Topics bzw. auch aus deren Inhalten.
Der ganze Arbeitsablauf klingt nach einer Menge Arbeit, oder? Doch das Gegenteil ist der Fall. Denn wir wurden durch ein „Automatic Semantic Tagging Modul“ unterstützt (inf. 01). Die Metadaten von iiRDS konnten wahlweise automatisch oder von Hand und mit Kontrolle vergeben werden. In unserem Fall ist zum Beispiel das Troubleshooting nicht als DITA-Topic, sondern als Tabelle gesammelt abgebildet. Die Tabelle wurde manuell so ergänzt, wie es für unseren Use Case nötig war, zum Beispiel mit dem „hydraulic oil sensor“.
Die Verknüpfungen zwischen den iiRDS-Metadaten kommen dabei automatisch durch das „iiRDS Core Schema“ und das „iiRDS Machinery Zusatzschema“ und können hier genutzt werden. [3]
Einfach anwenden
Der intelligent information Request and Delivery Standard schafft die Verbindungen zwischen Informationseinheiten und Produkteinheiten. Wir sind nach unserem Proof-of-Concept selbst überrascht, wie einfach wir iiRDS auf Basis der bestehenden Unternehmensstandards wie Terminologie und Produkthierarchien anwenden konnten. Dadurch, dass iiRDS ein offener Standard ist, kann die idividuelle Produkttaxonomie einfach mit den so genannten „Andockpunkten“ referenziert werden. Durch die Transformation der Terminologie in ein konzeptbasiertes SKOS-Taxonomie-Schema haben wir zudem unterschiedliche Ausdrucksformen (Synonyme „skos:altLabel“) eines Begriffes verwenden können und dies über alle Übersetzungen und Sprachen hinweg. Zum Zeitpunkt dieses Artikels wurde bereits der Auftrag für die unternehmensweite Realisierung gegeben. Um die Umsetzung von iiRDS-Projekten zu erleichtern, entsteht derzeit ein Referenzmodell für die Einführung des Standards. [6]
Links und Literatur zum Artikel
[1] Sandvik MB670-1 FLP Bolter Miner For Longwall Mining: https://www.rocktechnology.sandvik/en/products/equipment/mechanical-cutting/mb670-1-flp-bolter-miner/
[2] Schmidt, Martina (2024): Entwickeln eines Konzeptes zur Bereitstellung von Informationen aus einem DITA-basierten XML-Redaktionssystem auf einer Web-Plattform. Masterarbeit, FH Joanneum.
[3] Ziegler, Wolfgang (2022): Metadaten für intelligenten Content. In: Intelligente Information. Schriften zur Technischen Kommunikation, S. 51–56. tcworld GmbH: Stuttgart.
[4] iiRDS, the intelligent Information Request and Delivery Standard: www.iirds.org
[5] Kreutzer, Martin/Schubert, Mark (2024): Your way to iiRDS – Playing with the DITA Open Toolkit. Workshop auf der tekom-Jahrestagung.
[6] Kronfellner, Markus/Stadlbauer, Harald: A Reference Process Model for iiRDS Introduction, Internal Report, NINEFEB Technical Documentation.
