Digitale Betriebsanleitung ab 2027: Die Verordnung erlaubt mehr als ein PDF

Am 20. Januar 2027 wird die EU-Maschinenverordnung 2023/1230 in vollem Umfang anwendbar und löst die Maschinenrichtlinie 2006/42/EG ab. Ein Detail geht dabei oft unter: Es ist eine Verordnung, keine Richtlinie. Sie gilt unmittelbar in allen Mitgliedstaaten. Ein nationales Umsetzungsgesetz, auf das man noch warten könnte, gibt es nicht.

Für Maschinenbauer steckt darin eine Erlaubnis, über die erstaunlich wenig geschrieben wird.

Was Artikel 10(7) wirklich sagt

Die verbreitete Lesart lautet: Ab 2027 darf die Betriebsanleitung digital geliefert werden, als PDF mit QR-Code auf der Maschine. Das stimmt, ist aber nur die halbe Aussage.

Im Verordnungstext steht, dass die Anforderung auch dann gilt, wenn die Anleitung in der Software der Maschine eingebettet ist. Wörtlich: „this requirement also applies where the instructions for use are embedded in the software of the machinery". Die Verordnung denkt den Fall also ausdrücklich mit, dass die Anleitung kein separates Dokument mehr ist, sondern Teil der Bedienoberfläche.

Dieselbe Öffnung gibt es an zwei weiteren Stellen: Artikel 10(8) erlaubt die EU-Konformitätserklärung digital, erreichbar über eine Internetadresse oder einen maschinenlesbaren Code. Artikel 11(7) überträgt die Regelung auf die Montageanleitung unvollständiger Maschinen.

Die vier Bedingungen, die daran hängen

Die Erlaubnis ist an Pflichten geknüpft. Wer digital liefert, übernimmt diese vier:

Die zweite Zeile ist die interessanteste, und sie fehlt in den meisten Compliance-Übersichten. „Insbesondere bei einer Störung" heißt: Die Anleitung darf nicht ausgerechnet dann unerreichbar sein, wenn die Maschine steht und jemand sie reparieren muss. Eine Doku, die ausschließlich in einem Online-Kundenportal lebt, erfüllt das nicht zuverlässig.

„Zehn Jahre online" ist eine Architekturfrage, keine Hosting-Frage

Zehn Jahre sind in der Softwarewelt eine sehr lange Zeit. Denk daran, welche Werkzeuge du 2016 im Einsatz hattest, und wie viele davon es heute noch in derselben Form gibt.

Wer die Betriebsanleitung digital ausliefert, bindet seine Konformität für ein Jahrzehnt an einen Software-Stack. Das ist eine Entscheidung über Lieferantenrisiko, nicht über Hosting. Die eigentliche Frage lautet nicht „wo liegt die Doku", sondern: Was passiert mit meiner Auslieferung, wenn der Anbieter dahinter das Produkt einstellt, übernommen wird oder verschwindet?

Darauf gibt es eine Antwort, die unabhängig vom Anbieter funktioniert: Die ausgelieferte Doku darf kein Dienst sein, sondern muss ein Stapel Dateien sein. Kein Backend, keine Datenbank, kein Login-Server, kein Abo. Dann kannst du sie ablegen, wo du willst: auf deinem eigenen Webserver, in einem S3-Bucket, im Intranet des Endkunden oder auf einem USB-Stick, der der Maschine beiliegt. Ein statischer Webserver gehört zum Stabilsten, was es im Web gibt. Der läuft auch in zehn Jahren noch.

Für uns hat das eine unbequeme Konsequenz, die wir bewusst gezogen haben: Deine Auslieferung darf nicht davon abhängen, dass es realvirtual in zehn Jahren noch gibt. Deshalb ist der Viewer von realvirtual WEB Open Source (AGPL) und selbst hostbar. Du übergibst Dateien, hostest sie wo du willst, und sie laufen weiter, auch ohne uns. Unser Geschäft liegt auf der Authoring-Seite, nicht in der Auslieferung.

Welche Technologie trägt zehn Jahre?

Wer sich für die digitale Auslieferung entscheidet, wählt damit implizit eine Technologiebasis. Vier Kriterien entscheiden, ob sie das Jahrzehnt übersteht, unabhängig davon, für welches Produkt du dich am Ende entscheidest.

Verbreitung schlägt Spezialisierung. Eine Plattform mit großem Ökosystem überlebt einzelne Anbieter, weil es Entwickler, Dokumentation und Ersatzlösungen gibt. Eine Spezial-Engine, die nur ein Hersteller pflegt, steht und fällt mit diesem Hersteller. Das ist kein Qualitätsurteil über Nischenprodukte, sondern eine Aussage über die Ausfallwahrscheinlichkeit über zehn Jahre.

Offene Formate für die Geometrie. Ein Modell, das nur ein einziges Programm lesen kann, ist genau so langlebig wie dieses Programm. Formate wie STEP für CAD und glTF/GLB für die 3D-Auslieferung sind dokumentiert und werden von vielen Werkzeugen unterstützt. Proprietäre Binärcontainer sind der häufigste stille Lock-in.

Die Auslieferung sollte Standard-Web sein. Browser sind rückwärtskompatibler als fast jede andere Plattform. HTML und JavaScript von 2016 laufen heute noch. Ein natives Programm, das gegen eine bestimmte Windows-Version gebaut wurde, ist eine deutlich riskantere Wette. Der Endkunde müsste es außerdem installieren dürfen.

Trenne Authoring von Delivery. Das ist der wichtigste Punkt. Das Werkzeug, mit dem du den Zwilling baust, darf komplex sein, viel können und sich alle zwei Jahre ändern, denn es läuft bei dir im Engineering, vor dem Inverkehrbringen. Das, was du ausliefertst, muss das Gegenteil sein: so einfach und so stabil wie möglich. Wer beides in einem Stück ausliefert, vererbt jede Änderung am Werkzeug an eine Maschine, die zehn Jahre stillstehen soll.

Bei uns sieht dieser Schnitt so aus: Das Authoring passiert in Unity, einer Plattform mit sehr großem Ökosystem, mit vollem C#-Quellcode auf unserer Seite. Die Auslieferung ist ein Browser-Viewer auf Web-Standards, quelloffen unter AGPL und als statische Dateien übergebbar. Zwei Schichten, zwei Lebensdauern.

Ist Closed Source sicher genug, wenn der Anbieter verschwindet?

Diese Frage kommt in fast jedem Gespräch, und die ehrliche Antwort ist differenzierter als „open gut, closed schlecht".

Closed Source ist nicht das eigentliche Problem. Das Problem ist die Abhängigkeit: Läuft das, was du ausgeliefert hast, weiter, wenn der Anbieter dahinter das Produkt einstellt, übernommen wird oder Insolvenz anmeldet? Ein geschlossenes Engineering-Werkzeug, das du vor dem Inverkehrbringen benutzt, ist unkritisch: Geht der Anbieter unter, wechselst du beim nächsten Projekt das Werkzeug. Unangenehm, aber beherrschbar. Kritisch wird es erst bei dem Teil, der beim Endkunden zehn Jahre lang laufen soll.

Die klassische Antwort darauf ist die Quellcode-Hinterlegung (Source Escrow). Sie ist besser als nichts, hat aber drei bekannte Schwächen. Erstens ist der Auslöser meist eng definiert, typischerweise Insolvenz. „Produkt wurde abgekündigt" oder „Anbieter wurde übernommen und die Roadmap gestrichen" löst oft nicht aus, ist aber der viel häufigere Fall. Zweitens bekommst du Code, aber nicht zwangsläufig eine funktionierende Build-Umgebung, die passenden Abhängigkeiten und das Wissen, wie beides zusammengeht. Ein Paket, das nie jemand gebaut hat, ist ein Archiv, kein Notfallplan. Drittens hilft dir Quellcode nur, wenn du oder ein Dienstleister ihn tatsächlich übernehmen könnt.

Der praktikablere Test ist einfacher: Kannst du das ausgelieferte Artefakt weiterbetreiben, ohne dass irgendjemand etwas baut? Bei statischen Dateien auf einem Webserver lautet die Antwort ja. Da gibt es nichts, was ausfallen könnte, außer dem Webserver selbst, und den kontrollierst du. Bei einem gehosteten Dienst mit Lizenzserver lautet sie nein, unabhängig davon, ob der Code hinterlegt ist.

Daraus folgt eine praktische Regel: Frag beim Auswahlgespräch nicht „ist das Open Source?", sondern „was genau übergebe ich meinem Endkunden, und was davon braucht euch noch?" Die Antwort auf diese Frage entscheidet über dein Konformitätsrisiko, nicht das Lizenzmodell auf dem Datenblatt.

KI entwickelt sich schneller, als deine Maschine altert

Stell die beiden Zeitskalen nebeneinander. Eine Maschine steht zehn, oft zwanzig Jahre in der Halle, und die Doku-Pflicht dazu läuft mindestens ein Jahrzehnt. Die KI-Werkzeuge, mit denen heute selbstverständlich gearbeitet wird, gab es vor drei Jahren noch nicht. Sprachmodelle, die technische Dokumentation lesen und beantworten können, sind eine Entwicklung der jüngsten Zeit, und das Tempo lässt nicht nach.

Daraus folgt etwas Unbequemes: Du kannst heute nicht wissen, was 2032 an deine Maschinendokumentation angeschlossen wird. Wer sich jetzt für eine geschlossene Plattform entscheidet, die genau das kann, was ihr Anbieter vorgesehen hat, trifft diese Entscheidung für ein Jahrzehnt, auf dem Wissensstand von heute.

Das verschiebt den Blick auf das Maschinen-Informationssystem. Es ist nicht in erster Linie eine Anwendung, sondern eine Integrationsplattform: eine saubere Datenschicht aus Geometrie mit stabilen Komponenten-IDs, Signalen und strukturierter Dokumentation, erreichbar über offene, dokumentierte Schnittstellen. Was oben andockt, ist austauschbar: ein Diagnose-Assistent heute, etwas anderes in fünf Jahren. Die Schicht darunter bleibt.

Der Nutzen zeigt sich schon jetzt am Grounding-Problem: Ein Sprachmodell ohne Zugriff auf die Maschinendaten antwortet generisch und plausibel klingend, aber nicht auf deine Anlage bezogen. Eines, das die Komponenten-Doku deiner konkreten Maschine lesen kann, antwortet konkret und nennt die Quelle. Welches Modell das in fünf Jahren sein wird, weiß niemand. Genau deshalb sollte die Anbindung offen und die Datenschicht deine sein.

Bleibt der nüchterne Satz, der auch für uns selbst gilt: Das Web wird es in zehn Jahren noch geben. Deinen Softwareanbieter vielleicht nicht. Bau auf der Schicht, die überlebt, und halte alles darüber austauschbar.

Was das mit dem 3D-Modell zu tun hat

Wenn die Anleitung ohnehin in der Software stecken darf, stellt sich die Frage, warum sie ein 200-seitiges PDF bleiben sollte.

Der praktische Unterschied zeigt sich im Störfall. Klassisch sucht der Instandhalter die Teilenummer, blättert im PDF und gleicht Explosionszeichnungen ab. Mit dem 3D-Modell als Träger öffnet er die Maschine im Browser, klickt auf das Bauteil, und die zugehörige Dokumentation hängt daran: Datenblatt, Ersatzteilnummer, Wartungsschritt. Genau das meint der Begriff Maschinen-Informationssystem.

Das ist keine Zukunftsmusik, sondern eine Frage der Verknüpfung: Jede Komponente im 3D-Modell braucht eine ID, und jede Doku-Sektion muss auf eine existierende Komponente zeigen. Wer ohnehin ein Simulationsmodell der Maschine gebaut hat (für die Vertriebsvisualisierung oder die virtuelle Inbetriebnahme), hat diese Struktur bereits. Die Doku-Schicht kommt obendrauf; sie entsteht nicht bei null.

Der Zwilling endet nicht mit der virtuellen Inbetriebnahme

In den meisten Projekten hört der digitale Zwilling genau dort auf, wo er anfängt, sich zu rechnen. Das übliche Muster: Man baut ein Modell für die Vertriebsvisualisierung, erweitert es um Antriebe und Sensorik für die Konzeptsimulation, hängt eine echte Steuerung dran für die virtuelle Inbetriebnahme. Und wenn die Maschine ausgeliefert ist, wandert das Projekt ins Archiv.

Dabei sind das nur die ersten beiden von vier Stufen:

Die virtuelle Inbetriebnahme amortisiert sich einmal: kürzere Inbetriebnahme, weniger Fehler auf der Baustelle. Das ist ein guter Business Case, aber er endet mit der Abnahme. Stufe 4 amortisiert sich über die gesamte Lebensdauer der Maschine. Ab 2027 hast du für einen Teil davon ohnehin eine gesetzliche Verpflichtung.

Das ist der eigentliche Punkt: Das Modell, das du für die virtuelle Inbetriebnahme gebaut hast, ist bereits die Datenbasis für die digitale Betriebsanleitung. Die Geometrie stimmt, die Komponenten haben Bezeichner, die Signale sind definiert, die Kinematik ist beschrieben. Was fehlt, ist die Doku-Schicht darüber und ein Auslieferungsformat, das ohne Unity im Browser läuft. Das ist deutlich weniger Arbeit als ein zweites Projekt, aber nur, wenn du es von Anfang an mitdenkst statt das VC-Projekt abzuschließen und zwei Jahre später neu anzufangen.

Wer heute in virtuelle Inbetriebnahme investiert, sollte deshalb eine Frage vorab klären: Kommt aus derselben Werkzeugkette später auch das aus, was der Endkunde bekommt? Wenn Simulation und Auslieferung zwei getrennte Welten mit zwei getrennten Modellen sind, zahlst du die Modellierung zweimal.

Neu ab 2027: Cybersicherheit gehört zur Maschinensicherheit

Der zweite große Block der Verordnung wird seltener diskutiert, betrifft aber jeden, der ein modernes HMI baut. Anhang III führt den Schutz gegen Korruption, auch durch Angriffe (1.1.9), und die Zuverlässigkeit der Steuerung (1.2.1) als wesentliche Sicherheitsanforderungen. In der Maschinenrichtlinie von 2006 stand das so nicht.

Praktisch heißt das: Jeder Pfad, der aus einer Visualisierung heraus auf die Steuerung schreiben kann, ist ein potenzieller Angriffspfad und braucht dieselbe Sorgfalt wie jede andere sicherheitsrelevante Steuerungskomponente. Ein reines Anzeigesystem (Signale lesen, Doku zeigen, Alarme darstellen, ohne Schreibzugriff) ist deutlich einfacher zu bewerten. Für die meisten Erstprojekte ist das die vernünftige Ausgangsposition. Schreibzugriff kommt später, bewusst und getrennt bewertet.

Was du jetzt tun kannst

Ein halbes Jahr ist wenig für eine Entscheidung, die zehn Jahre trägt. Was sich jetzt lohnt:

• Kläre, ob du bei Papier bleibst oder digital lieferst. Beides ist erlaubt, aber digital ist eine Verpflichtung über zehn Jahre, keine Formatfrage.
• Wenn digital: Prüfe, ob deine Auslieferung ohne den Anbieter dahinter weiterläuft. Wenn nicht, trägst du ein Konformitätsrisiko, das du nicht kontrollierst.
• Prüfe das Offline-Kriterium konkret: Lässt sich die Doku drucken, herunterladen und bei stehender Maschine ohne Internetzugang öffnen?
• Prüfe die Technologiebasis auf Langlebigkeit: verbreitete Plattform, offene Formate, Auslieferung auf Web-Standards, und ein Artefakt, das ohne den Anbieter weiterläuft.
• Klär intern, wer die zehn Jahre verantwortet: Konstruktion, technische Redaktion oder IT. Diese Zuständigkeit existiert in vielen Häusern noch nicht.
• Wenn ohnehin ein 3D-Modell der Maschine existiert: Prüfe, was fehlt, um es als Doku-Träger zu nutzen. Meist sind es die Komponenten-IDs, nicht die Geometrie.

Kein Rechtsrat. Dieser Artikel fasst zusammen, wie wir die Verordnung für unsere eigene Produktarchitektur lesen. Verbindlich ist allein der Verordnungstext: Verordnung (EU) 2023/1230 auf EUR-Lex.

Ausführlicher haben wir das Thema im Ebook From Visualization to Action aufgeschrieben, veröffentlicht bei Unity: Teil 1: Machine Information Systems und Teil 2: The Reasoning Layer. Wenn du sehen willst, wie eine Maschine mit angehängter Doku im Browser aussieht: Live-Demo öffnen.

Häufige Fragen zur digitalen Betriebsanleitung