iiRDS für die Dokumentation Technischer Standards
Der Standard iiRDS macht Dokumentation smart – für ihre Auslieferung in Portalen, Apps und Datenbrillen. In Zusammenhang mit iiRDS werden sehr häufig Anwendungsbeispiele aus dem Bereich Maschinenbau genannt - zum Beispiel das Szenario der Service-Fachkraft, die mit einem Endgerät einen Fehlercode an der zu reparierenden Maschine scannt und anschließend auf dem Display den Informationsschnipsel zur Problembehebung empfängt [1].
Wir machen Ihre Dokumentation smart – mit iiRDS und intelligenten Informationen. Mehr erfahren.
Weniger thematisiert wurde bislang die Erweiterbarkeit des iiRDS-Modells für andere Bereiche und Anwendungen. In meiner Masterarbeit habe ich die Frage geklärt, ob und welche sinnvollen Umsetzungsmöglichkeiten für die Bereiche Technische Standards und Entwicklerdokumentation existieren. Dafür habe ich prototypisch iiRDS für die Auslieferung der Dokumentation von ASAM e.V. angewendet und laut iiRDS-Spezifikation [2] erweitert. ASAM entwickelt Technische Standards für den Automobilsektor [3].
ASAM e.V. – Dokumentation Technischer Standards
Die Masterarbeit habe ich in Zusammenarbeit mit ASAM e.V. erstellt. Die Standardisierungsarbeit von ASAM betrifft unter anderem die Bereiche Softwareentwicklung für elektronische Fahrzeugkomponenten, das Messen und Kalibrieren solcher Komponenten und die Simulation von Straßennetzen und Fahrfunktionen.
In der Masterarbeit habe ich die Dokumentation folgender ASAM-Standards verwendet:
- OpenDRIVE, ein Standard, der statische Aspekte der Straße beschreibt.
- OpenCRG, ein Standard, der ein Dateiformat für die Oberfläche der Straße definiert.
Die Dokumentation dieser Standards wird bei ASAM bereits topic-basiert verfasst, sodass ein gutes Maß an Standardisierung und Strukturierung vorhanden war - eine wichtige Voraussetzung, um die Dokumentation sinnvoll in einem iiRDS-Paket ausliefern zu können. Anschließend sollte die Dokumentation auf Basis von iiRDS in einem Content-Delivery-Portal bereitgestellt werden.
Standardisierungsdokumente sind bislang nicht in einer eigenen Domäne im iiRDS-Modell abgebildet, im Unterschied zu den existierenden Domänen iiRDSMachineryDomain und iiRDSSoftwareDomain. Es gibt auch keine Klassen und Instanzen, die sich ausschließlich mit Standardisierungsdokumentation befassen.
Zusätzlich interessant wurde das Vorhaben dadurch, dass ASAM in einem weiteren Projekt die fachlichen Konzepte von Verkehrsinfrastruktur und -simulation in Form einer Ontologie beschreibt [4]. Dadurch ergab sich die Möglichkeit, iiRDS mit einer Produkt-Ontologie zu verbinden. Dazu später mehr.
Festhalten der Anforderungen - User Stories
In einem ersten Schritt des Erstellungsprozesses haben wir die Anforderungen von ASAM erörtert und schriftlich festgehalten. Ausgehend von einem Interview mit ASAM-Verantwortlichen habe ich deshalb User Stories verfasst. Nachfolgend stelle ich einige davon beispielhaft vor, um die daraus entstandenen iiRDS-Erweiterungen und Such- und Filtermechanismen im Portal nachvollziehen zu können.
User Story, Beispiel 1: Standardübergreifende Suche nach Funktionen (Features)
Als Softwareentwicklerin möchte ich, dass ich verschiedene Standards nach bestimmten Features wie Roads oder Lanes durchsuchen kann, weil ich die Daten aus meinem Tool in verschiedene ASAM-Standards exportieren muss. Außerdem muss ich für jedes Feature wissen, wie das im jeweiligen Standard implementiert ist.
User Story, Beispiel 2: Überblick über Pflichtanforderungen
Als Produktmanagerin möchte ich einen Überblick über alle Pflichtanforderungen aus dem Standard erhalten, damit ich diesen Überblick zur Überprüfung der (oder als Input für die) Implementierungen verwenden kann.
Damit wird ausgedrückt, dass es möglich sein soll, nach den verpflichtenden Anforderungen, also nach Regeln, eines Standards zu filtern.
User Story, Beispiel 3: Release oder Concept
Als Softwareentwicklerin möchte ich sehen können, ob eine Information oder Anleitung, die ich in der Dokumentation gefunden habe, zu einem veröffentlichten ASAM-Standard gehört oder aus einem Konzept-Projekt stammt, damit ich einschätzen kann, ob ich die Datenstruktur sicher verwenden kann oder andernfalls sogar noch zum laufenden Projekt beitragen kann.
Ableiten von Metadaten aus den User Stories
Die User Stories dienten mir einerseits dazu, die Anforderungen von ASAM zu bestimmen. Andererseits habe ich die User Stories dazu verwendet, Metadaten festzulegen. Die Metadaten sollen dabei das Informationsbedürfnis abdecken, welches in den einzelnen User Stories beschrieben wird.
Für die Metadaten gibt es drei mögliche Quellen:
- Bestehende Klassen und Instanzen aus dem iiRDS-Modell
- OpenXOntology von ASAM
- Individuelle Erweiterung von iiRDS
Die meisten Metadaten konnte ich dem bestehenden iiRDS-Modell entnehmen. Dies zeigt, dass iiRDS ein umfassendes Vokabular für Technische Dokumentation abbildet. Für dieses Projekt waren nur punktuelle Erweiterungen notwendig.
Ein Beispiel für eine notwendige Erweiterung ist das Filtern nach Regeln: Die Anwender der ASAM-Standards wollen Regeln einsehen, die für die standardkonforme Modellierung von Straßen eingehalten werden müssen. In Unterkapiteln der Dokumentation wird das durch den Abschnitt „Rules“ gekennzeichnet. Vergibt man ein Metadatum für diese Abschnitte, kann dies im Portal als Suchfacette verwendet werden. Deshalb habe ich die Instanz Rules unterhalb der Klasse InformationSubject hinzugefügt.
Ein weiteres Beispiel ist die Unterscheidung zwischen veröffentlichten Standards und Konzeptprojekten: Für diesen Zweck habe ich eine Klasse ProductStatus mit den Instanzen ReleasedStandard und ConceptProject hinzugefügt.
Neben diesen zu erstellenden Klassen und Instanzen war ein weiterer zentraler Punkt die Anbindung der ASAM-eigenen Produkt-Ontologie (OpenXOntology) an die iiRDS-konforme Dokumentation. In der ASAM OpenXOntology sollen die Verkehrskonzepte und -definitionen aus verschiedenen ASAM-Standards zusammengeführt und gemeinsam beschrieben werden. In der Ontologie befinden sich zum Beispiel Definitionen von Konzepten wie Straßen (Roads) und Fahrspuren (Lanes). Sie betreffen das Produkt an sich, d.h. den ASAM-Standard, und nicht die Information in einer Dokumentation. Es handelt sich um produktbeschreibende Metadaten, die in iiRDS zumeist der Klasse ProductFunctions (Unterklasse von ProductFeature) hinzugefügt werden können.
Abbildung der Metadaten als semantisches Netz
Da mithilfe von iiRDS-Metadaten ein semantisches Netz entstehen soll, müssen die Metadaten zusätzlich miteinander verknüpft werden. Dies geschieht durch Relationen (Properties). Durch die Verbindung von zwei Instanzen von iiRDS-Klassen entsteht ein so genanntes Tripel, bestehend aus Subjekt - Prädikat – Objekt. InformationUnit ist die zentrale Klasse des iiRDS-Modells und stellt meistens das Subjekt des Tripels dar.
Nachfolgend finden Sie Beispiele für iiRDS-Tripel, die ich für die oben genannten User Stories verwendet habe:
- InformationUnit - relates to product variant – ProductVariant (OpenDRIVE | OpenCRG, …)
- InformationUnit - is applicable for document type – DocumentType (ConceptPaper | UserGuide)
- InformationUnit – relates to product status – ProductStatus (ConceptProject | ReleasedStandard)
- InformationUnit – has subject – InformationSubject (Rules)
- InformationUnit – relates to product feature – ProductFunction (Roads | Lanes | Junctions | …)
Die Erstellung eigener iiRDS-konformer Klassen und Instanzen
Nachdem ich alle Metadaten und Tripel festgelegt hatte, konnte ich mit der Modellierung eigener iiRDS-konformer Klassen und Instanzen beginnen. Um den Überblick zu behalten, habe ich eine Übersichtstabelle mit allen Erweiterungen erstellt:
Es ist wichtig, für die selbst erstellten Klassen und Instanzen eine IRI mit eigenem Namensraum zu vergeben. Ansonsten würde man ausdrücken, dass die eigenen Erweiterungen zum Standardvokabular von iiRDS gehören. Systeme, die iiRDS verarbeiten, erkennen die Erweiterungen nicht, sofern eine IRI aus dem iiRDS-Namensraum vergeben wird. Die Bezeichnung sollte so gewählt werden, dass sie auch zukünftig mit hoher Wahrscheinlichkeit eindeutig bleibt. Somit ist es sinnvoll, in der IRI Angaben zum Projekt und zum Ersteller der Klassen und Instanzen zu geben.
In der Tabelle habe ich einen eigenen Namensraum für die Klassen und Instanzen festgelegt.
Der Verweis auf die Produkt-Ontologie von ASAM erfolgt durch die Verwendung ihrer ASAM-spezifischen IRI (https://ontology.asam.net).
Die Klassen und Instanzen aus der Tabelle können anschließend mit einem beliebigen Text-Editor in das bestehende iiRDS-Modell integriert werden. Die nächste Abbildung zeigt beispielhaft die Erstellung einer eigenen Klasse UseCase als Unterklasse der bestehenden Klasse TopicType:
Das Hinzufügen eigener Instanzen zu bestehenden iiRDS-Klassen sieht folgendermaßen aus:
Dass die Instanz Rules bzw. Regeln zu einer bestehenden Klasse hinzugefügt wurde, erkennt man an den Start- und End-Tags. In diesem Fall ist dies iirds:Conformity. Mit dem Präfix iirds wird ausgedrückt, dass es sich nachfolgend um eine Klasse aus dem iiRDS-Modell handelt, hier Conformity. In dem folgenden rdf:about gibt man die IRI der Instanz an, die hinzugefügt werden soll. Hier zum Vergleich die Erstellung einer eigenen Instanz, die zu einer eigenen Klasse hinzugefügt wird:
Um die eigenen Erweiterungen zum iiRDS-Modell zu überprüfen und zu visualisieren, sind Ontologie-Editoren sehr nützlich. Dafür bietet sich zum Beispiel Protégé als Open-Source-Lösung an.
Die nächste Abbildung zeigt, dass die eigene Instanz Rules (unter Direct Instances) korrekt zur Klasse Conformity hinzugefügt wurde:
iiRDS-Generator - plusmeta
Um die Inhalte der Dokumentation mit den iiRDS-Metadaten zusammenzubringen, benötigt man einen iiRDS-Generator. Prinzipiell eignet sich dafür das iiRDS OpenToolkit, welches kostenfrei im Internet zur Verfügung steht. [5] Dieses bietet jedoch einen begrenzten Funktionsumfang. Beispielsweise können eigene Instanzen innerhalb bestehender Klassen hinzugefügt werden, eigene Klassen jedoch nicht. Aus diesem Grund habe ich für dieses Projekt mit der Software plusmeta gearbeitet. plusmeta bietet viele Funktionalitäten, welche weit über das Erstellen eines iiRDS-Pakets hinausgehen. [6] Praktisch daran ist, dass einige iiRDS-spezifische Metadaten im hinzugefügten Content automatisch erkannt werden. So müssen nicht mühselig alle Metadaten manuell zugewiesen werden. Für eigene Klassen und Instanzen funktioniert die automatische Erkennung zunächst natürlich nicht. Dafür bietet plusmeta jedoch die Möglichkeit, ein KI-Modell zu trainieren, um eigene Metadaten automatisch zu erkennen. Zusätzlich unterstützt plusmeta weitere Metadatenmodelle, wie z.B. VDI2770.
Umsetzung in einem CDP
Anschließend habe ich das fertige iiRDS-Paket in ein Content-Delivery-Portal integriert. Solche Portale bieten vielfältige semantische Abfrage- und Suchmöglichkeiten. Für dieses Projekt habe ich iv-content der Firma empolis intelligent views GmbH verwendet. Die Startseite des Portals sieht folgendermaßen aus:
In der mittleren Spalte kann man eine der Dokumentationen der Standards auswählen. Rechts sind verschiedene Metadaten aus dem iiRDS-Modell abgebildet. Klickt man auf eines dieser Metadaten, zeigt das Portal alle Topics an, die mit diesem Metadatum versehen sind:
Mit Klick auf „Table of Contents – ASAM OpenDRIVE v1.6 User Guide“ in der mittleren Spalte „Documents“ gelangt man zu folgender Ansicht:
Hier wird die Anwenderdokumentation des OpenDRIVE-Standards in einem Verzeichnis mit hierarchischer Kapitelstruktur angezeigt. Auch wenn iiRDS insbesondere für das kontext- und nutzergerechte Bereitstellen kleiner Topics gedacht ist, bietet das Modell durch den Einsatz sogenannter Directory Nodes ein übersichtliches Navigieren in einem Dokumentenkontext.
Wählt man eines der Topics aus, werden auf der rechten Seite einige Metadaten in sogenannten Kontext-Boxen angezeigt. Beispielsweise wird hier die Produktvariante bzw. der Standard des angezeigten Topics genannt, die darin vorkommenden inhaltlichen Themen (Angaben im Topic zu Architecture und Source code structure) und ein Verweis auf verwandte Themen (Related topics).
Des Weiteren bietet ein Suchfeld auf der Startseite eine Volltextsuche. Gibt man einen Suchbegriff ein (im folgenden Beispiel „Roads“), zeigt das Portal eine Liste mit allen Topics, die diesen Suchbegriff enthalten:
Zur Unterstützung der Volltextsuche bietet das Portal eine Eingrenzung der Suchergebnisse mithilfe von Facetten. Diese sind in Abbildung 10 links zu sehen. Die übergeordneten Facetten sind:
- Standard
- Feature
- Standard status
- Document type
- Type of information
- Type of topic
Dazu gibt es jeweils Unterfacetten, um die im Ergebnis angezeigte Liste mit Topics beliebig einzugrenzen.
Die folgenden Screenshots zeigen anhand der weiter oben erläuterten User Stories, wie Sie Informationen im Portal finden können.
User Story, Beispiel 1: Standardübergreifende Suche nach Funktionen (Features)
Ein wichtiger Use Case für die betreffenden Zielgruppen ist die standardübergreifende Suche nach Funktionen des Produkts. Dafür bietet iiRDS die Klasse ProductFeature an. In den OpenX Standards sind solche Funktionen beispielsweise Objekte wie Straßen, Fahrspuren oder Kreuzungen, deren Modellierung in den einzelnen Standards spezifiziert wird. Um diese Produktfunktionen zu finden, bietet das Portal die Möglichkeit einer facettierten Suche. Diese beginnt mit einer Volltextsuche zu einem Schlüsselwort oder auch mehreren Schlüsselwörtern auf der Startseite. Dies zeigt folgende Abbildung:
Anschließend werden alle Topics angezeigt, die das Schlüsselwort enthalten. In dieser Ansicht werden links die Facetten angezeigt, die ein Filtern in den Suchergebnissen ermöglichen. Dort kann nun nach der Produktfunktion gefiltert werden, zum Beispiel Straßen:
Die Suchergebnisse können durch Auswahl weiterer Filter eingegrenzt werden. Sinnvoll ist in diesem Kontext gegebenenfalls die Suche nach Produktfunktionen in einem bestimmten Standard:
Zusätzlich gibt es Filter für Dokument- und Informationsart, sodass man die Ergebnisse auch thematisch weiter eingrenzen kann.
User Story, Beispiel 2: Überblick über Pflichtanforderungen
Kennzeichnend für Standards ist die Angabe von Verbindlichkeitsgraden, für die die Schlüsselwörter shall, should, may, can existieren. Diese Verbindlichkeiten oder auch Pflichtanforderungen werden zumeist in einem eigenen Abschnitt der Dokumentation eines Standards erläutert. Das trifft auch auf die OpenXStandards zu. Durch die Auszeichnung mit einem Metadatum können diese Textabschnitte in einem Portal leicht gefunden werden. Damit ist es möglich einen Überblick über alle Pflichtanforderungen, die sich in einem Standard oder auch in mehreren Standards befinden, zu erhalten.
Um Informationen über Pflichtanforderungen zu erhalten, gibt es im Portal verschiedene Möglichkeiten.
Es ist möglich, genauso wie bei den Produktfunktionen, die Volltextsuche und anschließend eine Facettensuche zu nutzen:
Auch hier ist eine weitere Eingrenzung der Suchergebnisse möglich, zum Beispiel durch Auswahl eines bestimmten Standards:
Zusätzlich zur Volltext- und Facettensuche kann man auf der Einstiegsseite im Portal unter „Topics“ thematisch suchen. In dieser thematischen Suche gibt es den Unterpunkt „Regeln“, wie in folgender Abbildung dargestellt:
Anschließend werden standardübergreifend alle Topics angezeigt, die Pflichtanforderungen enthalten:
User Story, Beispiel 3: Release oder Concept
Die Entwicklung Technischer Standards dauert in der Regel mehrere Monate oder Jahre – so auch bei ASAM. Bevor eine erste oder neue Version eines Standards veröffentlicht wird, werden die neuen Features in einem so genannten Concept-Projekt spezifiziert und evaluiert. Die Concept-Dokumente werden ebenfalls veröffentlicht. Damit die Nutzer des Portals erkennen können, ob die Beschreibung eines Features zu einem Concept-Projekt oder zu einer veröffentlichten Version gehören, haben wir dieses Metadatum in die Dokumentenveröffentlichung aufgenommen:
Laufende Projekte im Bereich Digitalisierung von Normen und Standards
DiTraNo – Die digitale Transformation der Normung [7]
Thematisch sehr gut zum Thema der Masterarbeit passend, gab es im selben Zeitraum ein Projekt der „Deutschen Kommission Elektrotechnik Elektronik Informationstechnik in DIN und VDE“, kurz „DKE.“ Ziel des Projekts ist es, die maschinelle Weiterverarbeitung der DKE- Normen zu ermöglichen. Ein wichtiges Kriterium für DiTraNo ist die Auszeichnung der Inhalte nach ihrer Verbindlichkeit („muss“, „sollte“, „darf“, „kann“).
Die folgende Abbildung zeigt einen Ausschnitt des Prozesses der Klassifikation:
Auch im DiTraNo-Projekt wird iiRDS verwendet, um die Inhalte der Normen mit Metadaten auszuzeichnen.
Das Projekt wurde mittlerweile erfolgreich abgeschlossen und die Ergebnisse werden im Herbst 2021 in einem Abschlussbericht zur Verfügung gestellt.
Die Erkenntnisse von DiTraNo werden im Projekt IDiS, der Initiative Digitale Standards [8] weiterentwickelt. Ein Ziel von IDiS ist die praktische Umsetzung digitaler Standards für konkrete Produkte eines Industrieunternehmens. Als iiRDS-Konsortiumsmitglied arbeitet parson aktiv im IDiS-Projekt mit.
DIN – Smart Standards
Auch das Deutsche Institut für Normung e.V. (DIN e.V.) strebt eine Digitalisierung der Normung an. Der Titel des Projekts lautet Smart Standards. Auch hier wird eine maschinenlesbare Form der Normen angestrebt, die eine automatisierte Weiterverarbeitung ermöglicht. Dies ist bis zum Jahr 2030 geplant. Das Projekt ist somit in der Anfangsphase. In einem ersten Schritt wurde der Erstellungsprozess von Word auf XML umgestellt. Damit können die Normendokumente inhaltlich besser strukturiert werden. Als nächstes soll auch bei der DIN unter anderem eine Klassifikation nach Verbindlichkeit der Inhalte erfolgen und in maschinell auswertbarer Form vorliegen. Dafür ist eine semantische Anreicherung des Inhalts notwendig. Als nächstes sollen die Informationen aus den Normen in Ontologien abgebildet werden, sodass ein höherer Grad an Automatisierung gewährleistet wird und die Normeninhalte direkt in Softwaresystemen verwendet werden können. Ob und inwiefern iiRDS dabei zum Einsatz kommt, kann derzeit nicht abgeschätzt werden.
Fazit
Die Arbeit mit ASAM e.V. und die laufenden Projekte zur Digitalisierung im Normungsbereich zeigen, dass iiRDS als Ontologie im Dokumentationsbereich vielfältig angewendet werden kann. iiRDS ermöglicht eine optimale Ausweitung auf Arbeitsbereiche, die zwar angrenzen, bislang jedoch eher unter dem Radar blieben.
Sehen Sie auch in diesem Zusammenhang die Aufzeichnung des Vortrags von Patrick Schedlbauer und Ulrike Parson auf der tekom-Jahrestagung 2021:
Wir dokumentieren Ihre Technischen Standards. Mehr erfahren.
Fußnoten
[3] Details zum Ontologie-Projekt von ASAM e.V. findet man online unter: https://www.asam.net/project-detail/asam-openxontology/; zuletzt abgerufen am: 24.03.2021
[6] Unter folgendem Link findet man einige grundlegende Informationen zu diesem Projekt: https://www.dke.de/de/normen-standards (zuletzt abgerufen am: 19.09.2022)
[7] https://www.dke.de/de/news/projektabschluss-ditrano (zuletzt abgerufen am: 18.05.2021)
Neuen Kommentar hinzufügen