Systematisch integrieren

Text: Thomas Katzenmeier

Wie können Produktinformationen zwischen Maschinenhersteller und Kunde fließen? Oder zwischen Servicetechniker und Helpdesk, so dass sich eine Störung schnell eingrenzen lässt? Zum Beispiel mit iiRDS, denn der Standard vereinheitlicht Metadaten und ihren Austausch.

Inhaltsübersicht

Lesedauer: 08:50 Minuten

Die Abkürzung iiRDS steht für intelligent information Request and Delivery Standard. Damit ist die Bereitstellung und der branchen- und herstellerunabhängige Austausch intelligenter Information möglich [1]. Mit dem standardisierten Informationsaustausch können Maschinen- und Anlagenhersteller unterschiedlichen Kunden die benötigten Nutzungsinformationen bereitstellen. Die Kunden sind im Gegenzug in der Lage, Informationen verschiedener Hersteller ohne Zusatzaufwand in ihre Systeme und Abläufe zu integrieren. Hier ist aber nicht nur der Informationsaustausch zwischen Hersteller und Endkunde gemeint, sondern auch zwischen Zulieferern (OEM) und Herstellern.

Zum einen standardisiert iiRDS das Vokabular – die Metadaten, mit denen die Informationen ausgezeichnet werden, um sie eindeutig identifizieren zu können. Zum anderen legt der Standard ein Paketformat fest, mit dem die Inhalte zwischen den Anwendungen zur Informationserstellung (iiRDS-Generator) und der Informationspräsentation (iiRDS-Consumer) ausgetauscht werden können.

Informationsrecherche beschleunigen

Zur Informationspräsentation werden in erster Linie Content-Delivery-Portale (CDP) eingesetzt. Im Vordergrund stehen dabei das einfache Durchsuchen und das schnelle Auffinden von Informationen. Anstelle von monolithischen PDF-Dokumenten entstehen kleine Informationseinheiten (Topics), die mit Metadaten versehen und webbasiert zur Verfügung gestellt werden.

Über die Sucheingabe im CDP erhält der Nutzer eine Trefferliste. Mit der Facettennavigation können die Suchergebnisse auf Basis der Metadaten eingegrenzt werden. Am Ende wird dem Nutzer genau die Information angezeigt, die zu seinem Anwendungsfall passt (Abb. 01). Mit diesem Mechanismus der Facettensuche (Pull-Prinzip) können typische Anwendungsfälle zur Informationsrecherche beschleunigt werden, wie zum Beispiel das Auffinden technischer Informationen zu einem bestimmten Produkt. Verschiedene Softwarehersteller bieten Content-Delivery-Portale an, die dieses Anwendungsszenario abdecken.

Informationen können aber auch situationsbezogen angezeigt werden, ohne Sucheingabe (Push-Prinzip). Zwei Anwendungsbeispiele erläutern dies:

  1. gezielte Hilfe bei der Konfiguration und der Inbetriebnahme einer Maschine
  2. Informationen zur Instandhaltung und bei Servicefällen anhand von Statusinformationen der Maschine

Der Nutzer verwendet zur Umsetzung dieser Aufgaben typischerweise IT-Systeme, wie zum Beispiel Konfigurations- und Engineering-Software, Bedienterminals an der Maschine oder Service-Apps auf mobilen Endgeräten. Um nun Informationen passend zur Aufgabe oder zum Maschinenzustand anzuzeigen, übernimmt das jeweilige IT-System die Interaktion mit dem CDP. Das IT-System sendet mit Hilfe von Web-Services genau diejenigen Metadaten an das CDP, die das gewünschte Topic eindeutig identifizieren.

Vorstellbar ist auch, dass die Informationen nicht im CDP (Webbrowser oder Mobile App) angezeigt werden, sondern direkt im IT-System, zum Beispiel in der Bediensoftware auf dem HMI-Terminal. Als Frontend für den Nutzer dient also nicht das CDP, sondern das IT-System, mit dem er gerade arbeitet. Das Content-Delivery-Portal bleibt im Hintergrund als „Middleware“ und liefert dem IT-System die gewünschten Topics. Es stellt somit eine übergreifende Plattform für die intelligente Bereitstellung von Informationen in unterschiedlichen IT-Systemen dar. Der Maschinenhersteller bzw. Anlagenbauer könnte also die für seine Anwendungsfälle benötigten Inhalte ohne das Frontend des CDP in seine Software einbetten. Im Folgenden wird der Begriff Content-Delivery-System (CDS) stellvertretend für beliebige Varianten der Implementierung des Frontend verwendet.

Von der Eingabe zum Ergebnis.

Abb. 01 Facettensuche - Prozess von der Suche bis zur Darstellung des Ergebnisses.  Quelle Thomas Katzenmeier

Integriertes Hilfesystem

Neben den technischen Voraussetzungen muss dafür gesorgt werden, dass die einzelnen Informationsobjekte (Topics) genau die Informationen enthalten, die zur Bearbeitung des jeweiligen Anwendungsfalls passen. Bei der Inbetriebnahme einer Anlage mit einer Konfigurations- oder Engineering-Software sind das üblicherweise die Inhalte des Hilfesystems, die beispielsweise ein Dialogfenster oder eine spezifische Softwarefunktion beschreiben. Mit dem Aufruf über einen Hilfe-Button oder die Taste F1 löst die Software eine Anfrage an das CDS aus. Das CDS agiert als kontextsensitives Hilfesystem und liefert die passende Information. Die Abfrage an das CDS setzt sich dabei aus den Metadaten zusammen, die zur Identifizierung der jeweiligen Softwarefunktion herangezogen werden, etwa die Bezeichnung der Software, die vorliegende Softwareversion und die Softwarefunktion selbst (Abb. 02).

Übersicht über die Umsetzung einer kontextsensitiven Hilfe.

Abb. 02 Content-Delivery-System für kontextsensitive Hilfe.  Quelle Thomas Katzenmeier

Beim Erstellen der Inhalte für das Hilfesystem muss jedes Topic mit genau diesen Metadaten versehen werden, um es im Hilfesystem eindeutig identifizieren zu können. Im Gegensatz zum klassischen Hilfesystem – wie zum Beispiel CHM oder JavaHelp – wird das Hilfe-Topic also nicht über einen zusätzlichen Identifier, sondern über die jeweils zum Topic passenden Metadaten ausfindig gemacht. Das hat den Vorteil, dass genau die Metadaten, die bereits zur Klassifikation eines Topics im CDS verwendet werden, auch direkt für den Aufruf des Hilfe-Topics eingesetzt werden können. Ein zusätzlicher und oft fehleranfälliger Identifier-Mechanismus ist dadurch überflüssig. Die Nutzung des CDS als Hilfesystem bietet weitere Vorteile:

  • Kein zusätzliches Help-Authoring-Tool für das Erstellen der Inhalte des Hilfesystems – die Inhalte können im gleichen System erstellt werden, das auch für die sonstigen Inhalte des CDS verwendet wird (Single Sourcing).
  • Kein Datensilo – wenn die Inhalte für das Hilfesystem zusammen mit weiterführenden Inhalten im CDS vorliegen (zum Beispiel Inbetriebnahmeanweisungen oder technische Daten), kann der Nutzer über die Facettensuche des CDS weitere Informationen recherchieren.
  • Kein Medienbruch – eine einzige Style­sheet-Vorlage führt zu einem einheitlichen Layout für alle Inhalte des CDS und Hilfesystems.
  • Kein zusätzliches Publikationsformat – die Inhalte und Metadaten für das Hilfesystem können über das standardisierte iiRDS-Paketformat in das CDS übergeben werden.
  • 3rd-Party-Anbindung – einige Maschinenhersteller öffnen ihre Entwicklungsplattformen und erlauben anderen Unternehmen, System­funktionen als Apps zu implementieren und zu integrieren. Mit dem iiRDS-Austauschformat und den passenden Metadaten können diese Drittanbieter ihre App-Dokumentation kontext- sensitiv im gemeinsamen Hilfesystem zur Verfügung stellen.

Einige Beispiele für iiRDS-Metadaten zeigt Tabelle 01.

Tabelle mit iiRDS-Metadaten geordnet nach Metadatum, Verwendung und Beispielen.

Tab. 01  Quelle Thomas Katzenmeier

Metadaten als Schlüssel

Im zweiten Anwendungsbeispiel sollen Informationen zur Instandhaltung und für Service-Fälle bereitgestellt werden. Das hierfür eingesetzte IT-System, zum Beispiel eine Service-App auf dem Tablet oder Smartphone, kommuniziert direkt mit der Maschine oder Anlage. Der Mitarbeiter für die Instandhaltung scannt zunächst das elektronische Typenschild der Maschine. Die Service-App greift über eine WLAN-Verbindung auf die Diagnosedaten der Maschine zu und identifiziert ein Problem an einer Komponente, die möglicherweise tief in der Maschine verbaut ist. Mit den Metadaten etwa der Seriennummer oder Typenbezeichnung sowie der Statusinformation generiert die Service-App eine Abfrage an das CDS. In der Antwort liefert das CDS das passende Topic mit Informationen und Handlungsanweisungen zur Problembeseitigung (Abb. 03). Benötigte Werkzeuge, Ausrüstungen oder auch Ersatzteile können ebenfalls angezeigt werden.

Falls der Techniker das Problem nicht selbst beheben kann, braucht er möglicherweise Unterstützung über den Helpdesk. Hierzu kann die Service-App direkten Kontakt aufnehmen und die Metadaten übermitteln, so dass ein Helpdesk-Mitarbeiter das Problem bearbeiten und eine Lösung vorschlagen kann. Zusätzlich können die Metadaten genutzt werden, um die Service-App an Katalog-, Warenwirtschafts- oder Shop-Systeme zu koppeln und somit passend zum Servicefall Ersatz- oder Reparaturteile zu bestellen. Mit diesem oder ähnlichen Anwendungszenarien entstehen neue Geschäftsmodelle für Hersteller, Zulieferer und Dienstleister, kurz „Value Based Services“.

Übersicht über die einzelnen technischen Elemente zur genauen Darstellung des Maschinenzustands.

Abb. 03 Situationsbezogene Informationen anhand des Maschinenzustands.  Quelle Thomas Katzenmeier.

Offen für eigene Metadaten

iiRDS bietet standardmäßig ein Grund­gerüst an Metadatenklassen für die Technische Dokumentation und schlägt bereits einige gebräuchliche Metadaten vor. Diese lassen sich um herstellerspezifische Metadaten erweitern. Für die beiden Anwendungsbeispiele stellt iiRDS alle benötigten Metadatenklassen und Andockpunkte bereit:

  • Andockpunkte für Produktmetadaten (ProductMetadata) zur Klassifikation der Produkte und -varianten, der verbauten (Zuliefer-)Komponenten sowie deren Merkmale und Funktionen
  • Ereignisse, wie Maschinen-/ Anlagenzustände oder Fehlercodes (Event)
  • Thema (InformationSubject) und Typ (TopicType) der Information
  • Verortung der Information im Produkt­lebenszyklus (ProductLifeCyclePhase)
  • auszuführende Handlung (Action)
  • Informationen über Hilfsmittel, die bei der Handlung benötigt werden (Supply)
  • Qualifizierung und Rolle des Nutzers (SkillLevel und Role)

Während einige Metadaten bereits vordefiniert sind, müssen die Hersteller ihre produkt- und anwendungsspezifischen Metadaten ergänzen. So kann beispielsweise ein Zulieferer für elektrische Antriebe sein Klassifikationsschema für Fehlerzustände in der Klasse Event abbilden und seine Topics damit auszeichnen.

Produkte, Produktmerkmale sowie Bezeichnungen von Komponenten sind in iiRDS nicht festgelegt. Hier kann der Hersteller seine Produkthierarchie abbilden und gegebenenfalls bestehende Klassifizierungen aus ERP, PIM, Produktkonfiguratoren oder aus standardisierten Modellen wie ECLASS zuordnen [2]. Ebenso verhält es sich mit den Metadaten zu Hilfsmitteln, Handlungen, Qualifizierung und Rollen, die anwendungsspezifisch festgelegt werden müssen. Die Klasse InformationSubject enthält einige vordefinierte Metadaten, Beispiel: Konformitätserklärung. Fehlende Themen müssen jedoch ergänzt werden, Beispiel: Baumusterprüfung.

Einen Nenner finden

Um für herstellerübergreifende Informationen die Vorteile von iiRDS optimal zu nutzen, gilt es, den Informationsaustausch zu standardisieren. Dazu müssen Zulieferer und Hersteller bi- oder multilaterale Vereinbarungen treffen und ihre jeweiligen proprietären Klassifikationen zusammenführen. Wo sich keine Übereinstimmung finden lässt, können Metadaten gemappt werden. Diesen Weg sieht iiRDS vor, um ganze Ontologien unterschiedlicher Metadatenbezeichnungen gegenseitig abzugleichen und zuzuordnen. Hierzu ein Beispiel: Der Zulieferer bezeichnet eine Komponente als „Bedienterminal“. Der Maschinenbauer, der diese Komponente verbaut, nennt sie jedoch „Bediengerät“. Über den Mapping-Mechanismus können beide Benennungen zusammengeführt werden, ohne die Metadatenwerte zu verändern.

Das standardisierte Paketformat ermöglicht es, alle Inhalte mitsamt den Metadaten untereinander auszutauschen. Der Maschinenhersteller kann so die verschiedenen iiRDS-Pakete der Zulieferer in sein CDS integrieren, ohne die Inhalte weiter anpassen zu müssen. Dabei dürfen die Inhalte in beliebigen Dateiformaten vorliegen, etwa PDF, XML, HTML oder MP4. Hersteller und Zulieferer müssen sich auf die Dateiformate einigen. Wenn die Inhalte – wie für Content-Delivery-Systeme üblich – im HTML-Format bereitgestellt werden sollen, müssen die verwendeten HTML-Elemente falls nötig eingegrenzt und die Stylesheets darauf abgestimmt werden. Ein einfacher Weg, um dies zu erreichen, ist das so genannte iiRDS/A-Format. Dieses speziell für den Austausch definierte Format begrenzt die zulässigen Medienformate und den HTML-Sprachumfang [3].

Industrie 4.0 bietet Perspektiven

Neben der Standardisierung von Metadaten und dem Paketformat sollen auch die Möglichkeiten im Rahmen von Industrie 4.0 betrachtet werden. Industrie 4.0 bezeichnet die intelligente Vernetzung von Maschinen und Abläufen in der Industrie mit Hilfe von Informations- und Kommunikationstechnologie [4].

Verschiedene Arbeitsgruppen erarbeiten etwa die Entwicklung wichtiger Basistechnologien und technischer Konzepte für Industrie 4.0. Die teilnehmenden Unternehmen und Organisationen engagieren sich zum Beispiel für Konzepte zum digitalen Zwilling. In so genannten Verwaltungsschalen wird dieser Zwilling technisch umgesetzt. Unterschiedliche funktionale Aspekte einer Industrie-4.0-Komponente werden als Teilmodelle in einer Verwaltungsschale abgebildet. Einige Teilmodelle sind bereits umgesetzt oder befinden sich in der Abstimmung. Dazu zählen:

  • technische (Meta-)Daten für Industrieausrüstung wie Produktklassifikation (zum Beispiel nach ECLASS), Produktidentifikation und technische Merkmale
  • digitales Typenschild zur Produkt­identifikation industrieller Geräte
  • Mindestanforderungen für die Über­gabe-Dokumentation vom Her­steller an den Betreiber (nach VDI 2770)
  • Informationsaustausch zwischen Partnern in der Wertschöpfungskette von Industrie 4.0

Auf dieser Grundlage fügt sich auch die Technische Dokumentation als Teilmodell ein. Zurzeit werden die Anforderungen nur auf Dokumentebene nach dem Prinzip der VDI-Richtlinie 2770 festgelegt [5]. iiRDS betrachtet die Informationen hingegen umfassender und in einer feineren Granularität. Der Standard wurde im Juli 2020 in die „Deutsche Normungsroadmap Industrie 4.0“ des DIN/DKE aufgenommen [6]. Im Kontext von Industrie 4.0 soll iiRDS ermöglichen, situationsbezogene kontext­spezifische Informationen für die im Produktlebenszyklus vorkommenden Fälle zu erzeugen. Dabei sollen die Informationen folgende Anforderungen Industrie-4.0-konform erfüllen:

  • sich dynamisch an Benutzer und Anwendungskontext anpassen
  • zielgerichtet für alle Lebenszyklusphasen zur Verfügung stehen, von der Spezifikation bis zur Wartung
  • zum ausgelieferten System passen, auch nach Konfigurationsänderungen und Updates
  • Assistenz­ und Sensorinformationen sowie Betriebsparameter dynamisch integrieren
  • vielfältige Such­ und Filterfunktionen unterstützen

Diese Anforderungen lassen sich mit iiRDS in einem Teilmodell abbilden. „Intelligente Information“ wird damit weiter systematisiert, mit anderen Standards in Verbindung gesetzt und im digitalen Zwilling verfügbar gemacht. Absprachen zwischen Zulieferern, Herstellern und Betreibern werden zunehmend überflüssig. Es wird einfacher und attraktiver, Informationen untereinander auszutauschen. So können neue Anwendungen und Geschäftsmodelle entstehen – iiRDS wird dabei eine zentrale Rolle spielen. 

Links und Literatur zum Beitrag

[1] tekom (2018): iiRDS – The International Standard for intelligent information Request and Delivery. https://iirds.org

[2] ECLASS e. V.: ECLASS – Standard für Stammdaten und Semantik für die Digitalisierung. https://www.eclass.eu

[3] iiRDS Consortium (2020): tekom iiRDS Standard, Version 1.1. https://iirds.org/fileadmin/iiRDS_specification/20201103-1.1-release

[4] Bundesministerium für Wirtschaft und Energie: Plattform Industrie 4.0. https://www.plattform-i40.de

[5] VDI (2020): VDI 2770 Blatt 1. https://www.vdi.de/richtlinien/details/vdi-2770-blatt-1-betrieb-verfahrenstechnischer-anlagen-mindestanforderungen-an-digitale-herstellerinformationen-fuer-die-prozessindustrie-grundlagen

[6] DIN/DKE (2020): Deutsche Normungsroadmap Industrie 4.0. https://www.din.de/de/forschung-und-innovation/themen/industrie4-0/roadmap-industrie40-62178

Titelmotiv von Ausgabe 04 2021 der technischen kommunikation