So baut iiRDS/H eine Brücke

In der Technischen Dokumentation gilt es, unterschiedliche Standards und Anforderungen miteinander zu vereinbaren. Auf der einen Seite müssen Unternehmen gesetzliche Vorgaben erfüllen und eine konforme Übergabe Technischer Dokumentation sicherstellen. Auf der anderen Seite wächst der Bedarf, Informationen intelligent und kontextbezogen bereitzustellen, um Anwenderinnen und Anwendern genau die Inhalte zu liefern, die sie in ihrer spezifischen Situation benötigen.

iiRDS/H integriert die Vorgaben der VDI 2770 in den iiRDS-Standard. Variante H („Handover“) schlägt dazu eine Brücke zwischen Dokumentenübergabe einerseits und intelligenter Informationsbereitstellung andererseits. Diese neue Variante ist das Ergebnis enger Zusammenarbeit des Digital Data Chain Konsortiums und des iiRDS-Konsortiums und stellt einen Meilenstein in der Standardisierung Technischer Dokumentation dar.

Sowohl iiRDS als auch VDI 2770 haben das grundlegende Ziel, Technische Dokumentation strukturiert und standardisiert zu verteilen. Beide Standards liefern die Informationsbausteine zusammen mit Metadaten aus, unterscheiden sich jedoch grundlegend in ihrer Philosophie und ihrem Anwendungsfokus.

Das leistet VDI 2770

Die VDI 2770 ist bewusst restriktiv gestaltet und setzt klare Rahmenbedingungen. Sie basiert auf Dokumenten als kleinster Informationseinheit, schreibt das PDF/A-Format verbindlich vor und definiert präzise, welche Metadaten enthalten sein müssen. Diese Strenge mag auf den ersten Blick einschränkend wirken, hat aber erhebliche praktische Vorteile: Ersteller Technischer Dokumentation müssen sich kaum Gedanken über die Metadatenstruktur machen, da die Vorgaben klar definiert sind. Empfänger wiederum können sich darauf verlassen, dass sie standardisierte Informationen in einem vorhersehbaren Format erhalten.

Der Hauptanwendungsfall der VDI 2770 liegt in der normkonformen Übergabe Technischer Dokumentation. Im Mittelpunkt steht dabei die Übergabe von Produktdokumentation an den Betreiber oder Nutzer einer Maschine oder Anlage. Dabei spielt insbesondere die eindeutige Zuordnung zur konkreten Produktinstanz eine zentrale Rolle.

Das leistet iiRDS

Demgegenüber verfolgt iiRDS einen deutlich flexibleren Ansatz. Nach dem Motto „vieles kann, nichts muss“ können Inhalte in den unterschiedlichsten Formaten vorliegen – vom PDF-Dokument über kleine, modular aufgebaute HTML-Topics bis hin zu multimedialen Inhalten wie Videos, Audios und Animationen. Diese Flexibilität ist kein Selbstzweck. Vielmehr entspricht sie den Anforderungen moderner Technischer Kommunikation.

Der Fokus von iiRDS liegt auf dem Konzept der „Intelligent Information“. Das bedeutet: Mit Hilfe geeigneter, semantisch strukturierter Metadaten sollen Anwendern die benötigten Informationen passgenau zur Verfügung gestellt werden – zum richtigen Zeitpunkt, im richtigen Kontext und in der richtigen Granularität. Ein Servicetechniker, der an einer Maschine eine Wartung durchführt, benötigt andere Informationen als ein Bediener im Produktionsalltag oder ein Ingenieur bei der Inbetriebnahme. iiRDS ermöglicht es, diese verschiedenen Nutzerszenarien optimal zu bedienen, ohne dabei den Überblick über die Gesamtdokumentation zu verlieren.

Wie iiRDS/H entstanden ist

Die Standardisierungslandschaft in der Technischen Dokumentation ist komplex und vielschichtig. Neben den nativen Formaten von VDI 2770 und iiRDS existiert je ein Teilmodell für die Asset Administration Shell (AAS). Gleichzeitig ist iiRDS auf dem Weg, eine internationale Norm zu werden.

Um Konkurrenz zu vermeiden und Ressourcen zu bündeln, wurde eine Task Force gegründet. Ihre Aufgaben: die bewährten Vorgaben der VDI 2770 systematisch in iiRDS integrieren und mit iiRDS/H eine restriktive, zukunftsfähige Variante schaffen.

Die Neuerungen sollen nicht nur in iiRDS/H selbst einfließen, sondern auch in das Teilmodell für die Verwaltungsschale (Asset Administration Shell) übernommen werden. Damit könnte das Teilmodell der Verwaltungsschale perspektivisch als Basis für den digitalen Produktpass dienen – ein wichtiger Baustein für die Zukunft der Industrie. iiRDS/H ist in Version 1.3 von iiRDS enthalten. Die Version wurde Anfang November 2025 veröffentlicht.

Alles in einem Paket

Abbildung 01 zeigt den schematischen Aufbau von VDI 2770 und iiRDS/H. Beide Standards nutzen ZIP-Dateien als Containerformat. Sie dient als Container für alle relevanten Informationen. In beiden Standards sind Dateien für Metadaten (VDI2770_Main.xml, VDI2770_Metadata.xml vs. metadata.jsonld), Dokumente (305_montage.pdf) sowie eine tabellarische Inhaltsübersicht (VDI2770_Main.pdf vs. index.html) enthalten.

Abb. 01 Schematischer Aufbau von VDI 2770 und iiRDS/H. Quelle Gerhard Glatz

Die Metadaten enthalten Bezüge zum Dokument, zum Produkt und zum Hersteller. Die tabellarische Inhaltsübersicht bietet einen Überblick über alle enthaltenen Dokumente und die wichtigsten Metadaten in lesbarer Form. Das Dokument muss im PDF/A-Format vorliegen und gewährleistet somit, dass Dokumente auch in vielen Jahren noch darstellbar und lesbar sind. Zusätzlich sind auch weitere Formate zulässig, solange beide Versionen inhaltsgleich sind und sich nicht widersprechen.

Eine der wichtigsten technischen Neuerungen in iiRDS/H betrifft die Art und Weise, wie Metadaten serialisiert werden. In iiRDS werden Informationen grundsätzlich in Form von Tripeln beschrieben – nach dem Muster Subjekt, Prädikat, Objekt. Diese Tripelstruktur entspricht dem Semantic-Web-Ansatz und ermöglicht eine hohe semantische Präzision und Verknüpfbarkeit von Informationen.

Während bisher ausschließlich RDF/XML als Serialisierungsformat verwendet wurde, ist in iiRDS/H nun JSON-LD (JSON for Linked Data) vorgeschrieben. JSON-LD ist das modernere Format und bringt mehrere Vorteile mit sich. Es lässt sich webbasiert deutlich leichter verarbeiten, fügt sich besser in moderne Webarchitekturen ein und resultiert in der Regel in kleineren Dateigrößen als RDF/XML.

In iiRDS/H sind beide Varianten – sowohl JSON-LD als auch RDF/XML – obligatorisch. Dies mag zunächst wie eine Verdopplung des Aufwands erscheinen, dient aber der Kompatibilität in einer Übergangsphase. Längerfristig könnte das XML-Format aus dem Standard entfernt werden, so dass JSON-LD als alleiniges Serialisierungsformat übrig bleibt.

Metadaten als Rückgrat

Beim Vergleich der Metadaten zwischen VDI 2770 und iiRDS/H zeigen sich auf Paketebene viele Gemeinsamkeiten. Grundsätzlich lässt sich alles, was in VDI 2770 auf Paketebene enthalten ist, auch in iiRDS/H abbilden. Dennoch gibt es wichtige Unterschiede in der Umsetzung, die es zu verstehen gilt. Abbildung 02 zeigt die Metadaten aus VDI 2770 und stellt sehr grob eventuelle neue Konzepte bzw. Lücken iiRDS/H gegenüber.

Abb. 02 Metadaten aus VDI 2770 mit Konzepten bzw. Lücken von iiRDS/H. Quelle Gerhard Glatz

Die ID für InfomationUnits bzw. Dokumente ist in iiRDS weniger streng definiert als in VDI 2770. Die Spezifikation macht lediglich Empfehlungen statt harter Vorgaben: Die ID sollte global eindeutig sein, und die gleiche Dokumentinstanz sollte idealerweise immer die gleiche ID erhalten. Das bedeutet: Wenn ein Dokument aus einem Redaktionssystem veröffentlicht wird und einen Monat später erneut veröffentlicht wird, sollte die ID idealerweise gleichbleiben. Diese Empfehlung dient der Nachvollziehbarkeit und Konsistenz, ist aber keine zwingende Vorschrift.

Statt der Document-ID „Domain“ aus VDI 2770 gibt es in iiRDS/H das Information Object mit einer Partei und der Rolle „Creator“. Dies dient demselben Zweck: der eindeutigen Zuordnung der ID zu einer Organisation. Es folgt aber der semantischen Struktur von iiRDS.

Die Dokumentversion heißt in iiRDS nicht „Version“, sondern „Revision“. Dieser terminologische Unterschied ist marginal, die Funktion ist identisch: die Versionsnummer des Dokuments angeben, die zusammen mit der Document ID das Dokument bei mehreren Versionen eindeutig identifiziert.

Die Dokumentkategorien zur Klassifikation wurden von VDI 2770 in iiRDS/H übernommen, um den Umstieg zu erleichtern. Diese Kategorien sind nun in der iiRDS-Domäne „Handover“ enthalten – eine neu geschaffene Domäne speziell für den Hand­over-Anwendungsfall. Auf die Unterteilung in Gruppen, die in VDI 2770 existiert, wurde verzichtet.

Zusätzlich zur Übernahme der VDI-Kategorien bietet iiRDS/H die Möglichkeit, externe Klassifikationssysteme anzugeben. Dies können etablierte Standards wie ECLASS, Document Class Code oder weitere branchenspezifische Klassifikationen sein. Diese Flexibilität ermöglicht es Unternehmen, ihre bestehenden Klassifikationssysteme weiterzuverwenden und gleichzeitig die Anforderungen von iiRDS/H zu erfüllen.

Bei den beschreibenden Metadaten sind Sprache und Titel weiterhin vorhanden. Die Summary aus VDI 2770 heißt „hasAbstract“. Subtitle, Keywords und NumberOfPages sind entfallen.

Die Partei mit der Rolle „Author“ ist in iiRDS/H abbildbar und funktioniert analog zur VDI 2770. Das Digital File heißt in iiRDS „Rendition“. Abgesehen von der Namensänderung ist die Funktionalität identisch: Es wird auf eine konkrete Datei mit ihrem Format und Dateinamen verwiesen.

Mit „isVersionOf“ gibt es in iiRDS/H eine Beziehung zum InformationObject mit der Partei-Rolle „Author“. Diese Konstruktion dient dazu, die Rolle „Responsible“ abzubilden, die in VDI 2770 existiert. Die Umsetzung ist etwas komplexer als in VDI 2770, erfüllt aber denselben Zweck.

Auch in iiRDS/H gibt es den Lifecycle-Status, der den Bearbeitungsstatus eines Dokuments angibt. Anders als in VDI 2770 ist dieser Status hier nicht verpflichtend. Das Set Date ist in iiRDS/H weggefallen.

Bezüge zwischen Dokumenten lassen sich in iiRDS/H mit den neu eingeführten Relationen „is translation of“ und „is based on“ abbilden. Diese ermöglichen es, Beziehungen auszudrücken.

Produktidentifikation in iiRDS/H

Der Bezug zum Produkt erfolgt in iiRDS/H über eine Produktvariante mit angehängter Identity. Diese Identity-Struktur ermöglicht verschiedene Arten von Identifikatoren. An der Identity muss ein Identifier angegeben werden, etwa Seriennummern nach IEC 61406. Die Norm gilt als internationaler Standard für die Identifizierung von Produkten.

An der Identity hängt auch eine Identity Domain, die angibt, ob das referenzierte Produkt ein Produkttyp oder eine Produkt­instanz ist. Außerdem ist ein Verweis zur Partei mit der Rolle „Hersteller“ vorgesehen.

Zusätzlich zur Produktinstanz ist auch eine weitere Identity mit der Rolle „Produkttyp“ vorgeschrieben, die die Bezeichnung des Produkttyps angibt.

Bestimmte Angaben aus VDI 2770 wie Reference Designation, Equipment ID, Project ID oder Description können nicht direkt angegeben werden. Stattdessen gibt es in iiRDS/H weitere Identity Types, zum Beispiel für Artikelnummern oder Order Codes. Wenn auch diese nicht ausreichen, bietet iiRDS die Möglichkeit, eigene Custom-Erweiterungen zu definieren. Diese Flexibilität ermöglicht es, auch sehr spezifische Anforderungen abzubilden, die über die Standard-Metadaten hinausgehen.

Zulieferketten ohne Paket-Chaos

Ein wichtiges und praktisch relevantes Thema ist die Abbildung komplexer Zulieferbeziehungen. Produkte setzen sich meistens aus Komponenten verschiedener Hersteller zusammen. Diese Komplexität muss sich auch in der Technischen Dokumentation widerspiegeln.

In der VDI 2770 war es möglich, Pakete zu verschachteln – ein Paket konnte also weitere Pakete enthalten, die wiederum weitere Pakete enthalten konnten. Diese Verschachtelung sollte die Aggregation von Zuliefererdokumentation über die gesamte Zulieferkette hinweg ermöglichen.

In der Theorie klingt das elegant, in der Praxis führte die Verschachtelung jedoch zu erheblichen Problemen: Bei langen Zulieferketten mit vielen Stufen wurden die Pfadnamen extrem lang, wodurch beim Entpacken die Limitierung von Betriebssystemen erreicht wurde. Der Ausweg, nämlich manuelles Auseinanderpflücken der Ordnerstrukturen, ist mühsam und führt zu einem weiteren Problem: Der Bezug zwischen den Paketen geht verloren. Man weiß dann nicht mehr, welches Paket zu welcher Komponente gehört und wie die Hierarchie ursprünglich aufgebaut war.

Lösung: ein Komponentenbaum

iiRDS/H löst dieses Problem durch die Nutzung eines Komponentenbaums. Statt Pakete physisch zu verschachteln, wird eine logische Hierarchie zwischen Komponenten aufgebaut und vom Dokument auf die zugehörige Komponente verwiesen. Von der übergeordneten Komponente wird dann auf die untergeordnete Komponente verwiesen.

Ein Beispiel zeigt Abbildung 03: Von Komponente „Pumpe“ wird auf die Komponente „Motor“ und darin auf die Komponente „Schalter“ verwiesen. Über diese Beziehungen lässt sich ein kompletter Komponentenbaum aufbauen, der die gesamte Zulieferkette abbildet – ohne dass physische Verschachtelung notwendig wäre.

Abb. 03 Beispiel für die Beziehung von Komponenten, in dem Fall eine Pumpe, Motor und Schalter. Quelle Gerhard Glatz

Die Vorteile dieses Ansatzes sind vielfältig: Die Pakete bleiben flach, die Pfadlängen überschaubar. Gleichzeitig bleiben alle Beziehungen erhalten und maschinell auswertbar. Der Komponentenbaum kann in Dokumentenmanagementsystemen oder Viewer-Anwendungen visualisiert werden, ohne dass die zugrunde liegenden Dateien physisch verschachtelt sein müssen.

Es ist zwar weiterhin möglich, Pakete in iiRDS/H zu verschachteln, denn die Spezifikation verbietet es nicht explizit. Aus den genannten Gründen wird jedoch der Komponentenbaum-Ansatz ausdrücklich empfohlen und ist auch so in der Spezifikation dokumentiert. Dieser Paradigmenwechsel von physischer zu logischer Verschachtelung ist eine der wichtigsten praktischen Verbesserungen von iiRDS/H gegenüber VDI 2770.

Für wen es sich lohnt

iiRDS/H richtet sich an alle Industrieunternehmen, die nicht nur einfache PDF-Dokumente bereitstellen wollen oder bereits VDI 2770- oder iiRDS-Pakete ausgeliefert haben. Mit einem KI-gestützten Ansatz und menschlicher Kontrolle lässt sich die Erstellung solcher Pakete effizient automatisieren. Auf www.iirds.org ist die Spezifikation enthalten. Dort finden Sie auch das iiRDS Open Toolkit, mit dem sich einfache iiRDS-Pakete erstellen lassen. Ab Anfang 2026 wird zudem die Erstellung der Variante iiRDS/H unterstützt.

Die Technische Dokumentation steht vor großen Veränderungen. Digitalisierung, künstliche Intelligenz, vernetzte Produkte und neue regulatorische Anforderungen schaffen ein komplexes Umfeld. Dort braucht es Standards, die stabil und flexibel sind, die Sicherheit und Innovation ermöglichen. iiRDS/H ist ein wichtiger Schritt in diese Richtung.