Wenn dein Kunde eine Lizenz braucht, um den Zwilling zu öffnen, den du ihm geschickt hast, dann hast du ihm keinen Zwilling geschickt.

Das ist kein Seitenhieb. Wir haben solche Dateien jahrelang selbst ausgeliefert.

Die 3D-Geometrie war nie das Schwierige. Ein GLB geht überall auf. Alles, was die Maschine zur Maschine macht, kommt daneben: eine AutomationML-Datei für die Topologie, eine Tabelle mit den SPS-Symbolen, ein PDF, das die Kinematik erklärt, weil es keinen anderen Platz dafür gab. Fünf Jahre später liegt dieser Ordner auf einem Share, den niemand mehr pflegt.

Keines dieser Formate ist schlecht. glTF macht Geometrie richtig. AutomationML und AAS meinen es ernst mit Semantik, seit Jahren. FMI hat Co-Simulation gelöst, bevor die meisten von uns das Thema überhaupt hatten. Das Problem ist, dass eine Maschine all das gleichzeitig ist, und die Dateigrenzen interessiert das nicht.

Und ein Format scheitert fast nie an der Spezifikation. Es scheitert daran, dass es niemand schreibt, oder daran, dass das eine Werkzeug, das es öffnet, fünfstellig kostet. Ein Kunde, der den ausgelieferten Zwilling nicht öffnen kann, ohne vorher die Software zu kaufen, in der er gebaut wurde, hat nicht wirklich etwas bekommen. Egal, was auf dem Lieferschein steht.

Was wir aufgeschrieben haben

Also haben wir aufgeschrieben, was wir intern ohnehin schon gemacht haben, und eine Versionsnummer drangeschrieben. rv-ODT legt Antriebe, Sensoren, SPS-Signale und Roboterkinematik in node.extras einer ganz normalen glTF-Datei ab. Ein GLB. Keine Begleitdateien, keine Schema-Registry, und zum Lesen braucht es nichts von uns.

Es bleibt gültiges glTF. Zieh es in einen Viewer, der noch nie von uns gehört hat, und die Geometrie geht auf. Enums sind Strings, Einheiten sind UCUM-Codes. Damit liest du eine Datei, die du noch nie gesehen hast, ohne vorher das Schema zu holen.

Genau das ist die Designentscheidung, die wir am härtesten verteidigen würden: Enums als Strings, niemals als Integer. Das kostet ein paar Bytes und sorgt dafür, dass eine Datei von 2026 im Jahr 2036 noch von einem Menschen lesbar ist, ohne Schema daneben. Alles andere in der Spezifikation ist verhandelbar.

Warum glTF und nicht USD

Unterschiedliche Aufgaben, und das haben Khronos und AOUSD 2023 in ihrer Liaison selbst so festgehalten: USD komponiert und erstellt Szenen, glTF liefert sie aus. glTF 2.0 ist heute ISO/IEC 12113. OpenUSD hat im Dezember 2025 seine erste Core Specification veröffentlicht und ist im Juli in den ISO-Prozess eingetreten. Beide wird es weiter geben. Wir lesen USD bereits in realvirtual WEB, und eine ODT-Datei lässt sich in eine USD-Stage referenzieren wie jedes andere glTF.

Offen, und was es kostet

Spezifikation und Schema stehen unter CC BY 4.0, die Referenzimplementierung unter AGPL. Die Schema-URL bleibt mindestens bis 2037 erreichbar. Das klingt nach einem Detail, bis man nachliest, was die Dokumentationspflichten ab 2027 an Öffnungsfähigkeit erwarten.

Es ist ein Anspruch, den wir selbst erfüllen müssen, deshalb unmissverständlich zum Geld: Eine ODT-Datei zu lesen kostet nichts und wird nie etwas kosten. Sie zu schreiben, da sitzt unser Produkt. Export aus realvirtual Professional heute, freies Bearbeiten in realvirtual WEB kommt.

Du willst ODT in deinem eigenen Werkzeug oder deiner Pipeline? Die Spezifikation reicht zum Anfangen. Keine Lizenz, keine Registrierung, kein Gespräch mit uns vorab: realvirtual.io/doc/web/odt. Wenn etwas darin unklar ist, sag uns Bescheid, dann korrigieren wir die Spezifikation.

Und wenn du täglich mit AutomationML oder AAS arbeitest und findest, dass wir hier etwas falsch dargestellt haben, sag uns wo. Uns ist eine korrigierte Spezifikation lieber als eine verteidigte.