Von der Visualisierung zur Aktion: Unity, Maschineninformationssysteme, KI-Agenten und der industrielle digitale Zwilling

Ein praktischer Leitfaden für Systemintegratoren, OEMs und Automatisierungstechniker

In Zusammenarbeit mit Thomas Strigl, CEO, realvirtual.io

Über den Autor: Thomas Strigl ist CEO von realvirtual.io und verfügt über 18 Jahre Erfahrung in Simulations- und Automatisierungssoftware.

Einleitung

In unserer vorherigen Anleitung Design, Simulation, Deploy: Why Unity Matters for Industrial Digital Twins, wir diskutierten Unity als Plattform für den Bau von Echtzeit-3D-Repliken industrieller Systeme. Die dort vorgebrachten Argumente gelten weiterhin. In dieser umfassenden zweiteiligen E-Book-Reihe konzentrieren wir uns auf zwei Themen, die sich zunehmend mit dieser Grundlage überschneiden:

Schnelle Entwicklung großer Sprachmodelle, KI-Agenten und des Model Context Protocol (MCP): Diese haben sich nun von Forschungskontexten zu Tools entwickelt, die einige Integratoren in Produktionsumgebungen einsetzen.

EU-Maschinenverordnung (EU) 2023/1230: Die Verordnung wurde 2023 verabschiedet, und ihr vollständiger Geltungsbeginn — der 20. Januar 2027 — ist weitgehend bekannt. Was sich jetzt ändert, ist die zeitliche Nähe zum Termin. Was sich jetzt ändert, ist die zeitliche Nähe zum Termin. In weniger als zwei Jahren nimmt der Rahmen Gestalt an: Harmonisierte Normen werden überarbeitet, der Anwendungsleitfaden erarbeitet und Maschinenbauer gehen vom Bewusstsein zur Umsetzung über. Neue Cybersicherheitsbestimmungen werden zu betrieblichen Anforderungen, während die ausdrückliche Unterstützung strukturierter digitaler Dokumentation die Dokumentation von einer statischen Liefermöglichkeit hin zu einer gewarteten Lebenszyklusressource verlagert.

Diese beiden Entwicklungen werden üblicherweise getrennt diskutiert. Diese E-Book-Reihe diskutiert sie gemeinsam, da sich die zugrunde liegende Arbeit deutlich überschneidet. KI-Systeme benötigen strukturierte, geerdete Daten. Eine strukturierte digitale Dokumentation, die für die Einhaltung gesetzlicher Vorschriften vorbereitet wurde, kann auch als Grundmaterial für industrielle KI-Systeme dienen. Die in Teil 1 beschriebene vierschichtige Architektur – Signale, MES-Kontext, Dokumentation und räumlicher Kontext – unterstützt sowohl den Bediener als auch später hinzugefügte KI-Tools.

Beim 3D HMI — genauer gesagt beim Maschineninformationssystem, das entsteht, wenn Maschinendaten, Unternehmenskontext und strukturierte Dokumentation in dieselbe räumliche Oberfläche integriert werden — treffen Maschinendaten, Dokumentation und KI-generierte Informationen für den Bediener zusammen.

Dabei geht es nicht darum, Behauptungen über die KI, die die Fabrik transformiert, aufzustellen, sondern praktische architektonische Muster zu beschreiben, die Integratoren unter Verwendung von Werkzeugen und Standards, die bereits vorhanden sind, nützlich finden können. Die Architektur steht allein für ihren operativen Wert; die Verordnung macht den Zeitpunkt für den europäischen Markt einfach deutlicher.

Teil 1

Die verbundene Schicht: Daten, Dokumentation und 3D HMI

1. Jenseits des digitalen Zwillings

Im vorherigen E-Book wurden Digital Twins als Werkzeuge diskutiert, die nützlicher werden, wenn sie sich mit realen Automatisierungssystemen verbinden und das reale Maschinenverhalten über den gesamten Lebenszyklus hinweg widerspiegeln. Diese Grundlage prägt bis heute den Umgang von Herstellern mit der digitalen Transformation.

Bei Systemintegratoren geht es in der Regel weniger um visuelle Qualität als vielmehr um Integration. Eine Verpackungslinie, ein Staplerkran oder ein verteiltes Lager muss funktionsfähig, tragfähig und wartungsfähig sein – oft für zehn Jahre oder länger. Die relevante Frage wird, wie gut der digitale Zwilling die Daten, die Menschen und die Dokumentation verbindet, die das System über seine Betriebsdauer tragfähig machen.

Die operativen Vorteile dieser Art integrierter Umgebung sind erheblich und unabhängig von jeglichem regulatorischen Zusammenhang:

• Schnellere Fehlerdiagnose:

Ein mit laufenden Maschinen- und Prozessdaten verbundenes 3D HMI verkürzt die Fehlerdiagnosezeit, da der Bediener die betroffene Komponente im räumlichen Kontext sehen kann, anstatt einen symbolischen Fehlercode auf einen physikalischen Ort abzubilden.

• Verringerung der Fachwissenshürde:

Senkt die Erfahrungsschwelle für neue Mitarbeiter, Schichtarbeiter und rotierendes Personal – relevant in nahezu allen Industriebranchen angesichts des gut dokumentierten Mangels an qualifizierten Technikern in mechanischen und elektrischen Bereichen.

• Effektive Fernunterstützung:

Macht Remote-Support sinnvoll, denn der Servicetechniker des Herstellers sieht, was der Bediener sieht, im gleichen 3D Kontext und kann genaue Anweisungen geben.

• Schulung ohne Produktionsunterbrechung:

Ermöglicht das Training gegen die tatsächliche Maschinenkonfiguration, ohne die Produktion zu stoppen.

• Betriebskontext auf Maschinenebene:

Wenn schließlich Maschineninformationssystemdaten – Aufträge, Chargen, KPIs, Energiezahlen – in derselben 3D Ansicht eingeblendet werden, sieht der Bediener nicht nur, ob eine Maschine läuft, sondern auch, wie sie im Kontext funktioniert.

Diese Vorteile entstehen unabhängig davon, ob ein Dokumentationspaket gesetzlich vorgeschrieben ist. Sie sind der operative Fall für die Architektur, die dieser Leitfaden beschreibt. Der in Abschnitt 3 erörterte Regelungsfall läuft parallel: Die strukturellen Änderungen, die die neue EU-Maschinenverordnung vorsieht, stimmen zufällig mit derselben Architektur überein, was bedeutet, dass sich die Regelungsarbeit und die operative Arbeit überschneiden, anstatt um separate Budgets zu konkurrieren.

Dadurch verschiebt sich die Rolle des digitalen Zwillings. Das 3D Modell ist nicht nur eine Visualisierung, es kann auch als räumlicher Index dienen, der Signale, Unternehmensdaten und Dokumentation in einer Form zusammenführt, in der Bediener und zunehmend KI-Tools navigieren können.

2. Die vier Datenschichten hinter einem funktionierenden digitalen Zwilling

Ein im Betrieb verwendeter digitaler Zwilling interagiert typischerweise mit vier unterschiedlichen Datenschichten. Jeder für sich ist unvollständig.

Die Signalschicht ist die schnellste und niedrigste. SPS-Ein- und Ausgänge, Antriebspositionen, Sensorzustände, Alarme – Werte, die sich in Millisekundenzyklen ändern. Dies ist die Schicht, die virtuelle Inbetriebnahme und Verhaltenssimulation bereits verwenden, typischerweise über OPC UA, Beckhoff ADS, Siemens S7 TCP/IP oder MQTT. Für die meisten digitalen Zwillingsanwendungen ist ein Aktualisierungszyklus im Bereich von 10–50 ms ausreichend.

Die MES-Schicht ist langsamer und breiter. Produktionsaufträge, Chargen, Rezepturen, Kennzahlen, Materialflüsse, Qualitätsnachweise, Energiezahlen. Diese Daten sind ereignisgesteuert und werden typischerweise über REST APIs, OPC UA, Message Broker oder direkte Datenbankverbindungen abgerufen. Diese Schicht liefert den Kontext, der Signaldaten interpretierbar macht: Derselbe Förderer, der mit der gleichen Geschwindigkeit läuft, hat eine unterschiedliche Bedeutung, je nachdem, welchen Auftrag er gerade verarbeitet.

Die Dokumentationsschicht ist diejenige, die historisch am wenigsten Beachtung gefunden hat. Betriebsanleitungen, elektrische Schaltpläne, P&ID-Diagramme, Risikobewertungen, Konformitätserklärungen, Stücklisten, Softwareversionen, Wartungsverfahren, Servicehistorien. In den meisten Installationen existiert diese Ebene als Binder, Netzwerkfreigabe oder PDF-Archiv – durchsuchbar nur von Menschen, die wissen, wonach sie suchen. Im Rahmen der neuen EU-Maschinenverordnung ändert sich die Struktur dieser Schicht, was Gegenstand des nächsten Abschnitts ist.

Die räumliche/kontextuelle Schicht ist das 3D Modell selbst. Es kann als vereinigendes Koordinatensystem über die anderen drei Schichten dienen. Eine Signaladresse ist abstrakt; dasselbe Signal, das auf ein bestimmtes Ventil abgebildet wird und das ein Bediener sehen und anklicken kann, ist direkter interpretierbar.

3. Dokumentation nach der neuen Maschinenverordnung

Seit mehr als einem Jahrzehnt unterliegt die technische Dokumentation von Maschinen, die in Europa in Verkehr gebracht werden, der Maschinenrichtlinie 2006/42/EG. Die bekannten Verpflichtungen – eine technische Akte gemäß Anhang VII, Gebrauchsanweisungen, eine EG-Konformitätserklärung, eine 10-jährige Aufbewahrungsfrist – wurden in der Regel durch gedruckte Handbücher, PDF-Archive und Papiererklärungen erfüllt.

Dieser Rahmen wird ersetzt. Die Verordnung (EU) 2023/1230, die neue Maschinenverordnung, wurde am 14. Juni 2023 erlassen und tritt am 20. Januar 2027 vollständig in Kraft. Sie hebt die Richtlinie 2006/42/EG auf und gilt als Verordnung und nicht als Richtlinie direkt in allen EU-Mitgliedstaaten, ohne dass es einer nationalen Umsetzung bedarf.

Die Verordnung steht schon seit einiger Zeit in den Büchern, aber der Rahmen wird noch fertiggestellt. Der Normungsantrag der Kommission an CEN und CENELEC wurde im Januar 2025 angenommen, mit dem Ziel, bis Ende 2026 einen vollständigen Satz harmonisierter Normen im Amtsblatt zu veröffentlichen. Die ersten Entwürfe des offiziellen Bewerbungsleitfadens werden ab Anfang 2026 erwartet, die endgültige Veröffentlichung voraussichtlich Ende 2026. Die praktische Dolmetscharbeit findet jetzt statt, und Projekte, die ab dem 20. Januar 2027 in Verkehr gebracht werden, müssen eingehalten werden.

Bevor ich die Änderungen beschreibe, noch ein wichtiger Hinweis, denn er wird weithin falsch gelesen: Die Papierdokumentation ist nach der neuen Verordnung weiterhin vollständig konform. Die unten beschriebenen Änderungen gelten für Hersteller, die sich für die digitale Bereitstellung von Dokumentation entscheiden – ein Weg, den die Verordnung nun ausdrücklich eröffnet, aber nicht vorschreibt.

Drei Änderungen der Verordnung sind besonders für Maschinenbauer und Systemintegratoren relevant. Die entsprechenden Artikel sind wörtlich im Anhang wiedergegeben.

Digitale Dokumentation ist nun ausdrücklich erlaubt: Gemäß Artikel 10 Absatz 7 können Gebrauchsanweisungen in digitaler Form bereitgestellt werden. Gemäß Artikel 10 Absatz 8 kann die EU-Konformitätserklärung digital, über eine Internetadresse oder einen maschinenlesbaren Code zugänglich gemacht werden. Montageanleitungen für teilweise fertiggestellte Maschinen (Artikel 11) können auch digital geliefert werden. Papier muss weiterhin auf Anfrage erhältlich sein, und bestimmte sicherheitskritische Informationen für nichtprofessionelle Anwender müssen auf Papier bleiben.

Für Hersteller, die sich für den digitalen Weg entscheiden, muss die Dokumentation mindestens zehn Jahre nach dem Inverkehrbringen der Maschine oder für die voraussichtliche Lebensdauer der Maschine online zugänglich bleiben, je nachdem, welcher Zeitraum länger ist. In der Praxis sind es selten nur zehn Jahre: Industriemaschinen arbeiten routinemäßig für fünfzehn, zwanzig oder sogar dreißig Jahre, so dass die Lebensdauerklausel die verbindliche Einschränkung für die meisten Anlagen ist und nicht die 10-Jahres-Baseline. Der Hersteller bleibt dafür verantwortlich, die Dokumentation über den gesamten Lebenszyklus erreichbar, aktuell und versionsgesteuert zu halten.

Cybersicherheit wird als wesentliche Gesundheits- und Sicherheitsanforderung hinzugefügt. Anhang III in den Abschnitten 1.1.9 (Korruptionsschutz) und 1.2.1 (Sicherheit und Zuverlässigkeit der Kontrollsysteme) schreibt vor, dass die Kontrollsysteme vernünftigerweise vorhersehbaren böswilligen Versuchen widerstehen müssen, die zu einer Gefahrensituation führen könnten. KI-basierte Sicherheitsfunktionen und selbstlernende Systeme fallen ausdrücklich in den Geltungsbereich, mit einer strengeren Konformitätsbewertung für Risikokategorien.

Die praktische Konsequenz ist, dass Hersteller, die den digitalen Weg wählen, von einer einmaligen Lieferung zu einer gewarteten, strukturierten Online-Ressource übergehen, die während ihrer Betriebsdauer neben der Maschine lebt. Die Papierzustellung bleibt eine voll konforme Alternative und bleibt für sicherheitskritische Informationen, die sich an nicht professionelle Anwender richten, verpflichtend.

Was die neue Verordnung für Hersteller bedeutet

Eine damit verbundene praktische Frage ist, wie die vom Lieferanten bereitgestellten Komponentendaten – für Antriebe, Sensoren, Ventile, SPS, Sicherheitskomponenten, IO-Link-Master – in die technische Datei des Herstellers einfließen. Das strukturierte Format mit dem meisten Schwung ist hier die Asset Administration Shell (AAS), eine maschinenlesbare digitale Zwillingsspezifikation für einzelne Komponenten, die von IEC 63278 und der Industrial Digital Twin Association (IDTA) definiert wird.

Eine AAS-Instanz führt Typenschilddaten, technische Spezifikationen, Dokumentation und Submodelle (für Sicherheit, Energie, Wartung) für eine spezifische Komponente in einer standardisierten Form, die jeder AAS-fähige Verbraucher lesen kann.

AAS ist noch nicht der universelle Industriestandard – die Akzeptanz ist teilweise, das Ökosystem reift noch aus und viele Zulieferer beginnen erst mit der Veröffentlichung –, aber es kommt auf den Verlauf an: Sobald eine kritische Masse von Zulieferern AAS-Teilmodelle ausliefert, wird eine strukturierte elektronische Dokumentation, die der Verordnung (EU) 2023/1230 entspricht und gleichzeitig KI-basierte Diagnosen begründet, zu einer Konfigurationsfrage und nicht zu einem manuellen Integrationsprojekt.

Zu den Zulieferern, die bereits AAS-Teilmodelle veröffentlichen, gehören Siemens (SIMATIC S7-1500), Festo (VTSA-Ventilanschlüsse), ABB (ACS880-Antriebe), Pepperl+Fuchs (IO-Link-Master), WAGO und Murrelektronik. Die Behandlung von AAS als Standardformat für Lieferanten-Input macht die Komponentenkette über die Lebensdauer der Maschine rückverfolgbar – was die Verordnung für die technische Dokumentation der Maschine vorschreibt – und ermöglicht die Skalierung der strukturierten Dokumentation, auf die das Maschineninformationssystem Laufzeit verweist (in der Referenzarchitektur in Abschnitt 6 als Lieferanten-AAS-Input dargestellt).

4. Vom 3D HMI zum Maschineninformationssystem

Im vorherigen E-Book wurde das 3D HMI als Visualisierungsschicht beschrieben, die den Maschinenzustand im räumlichen Kontext widerspiegelt. Mit dem Hinzufügen der MES- und Dokumentationsschichten entwickelt sich dasselbe 3D HMI zu etwas Größerem: einem Maschineninformationssystem — einer einzigen räumlichen Oberfläche, die Maschinenzustand, Unternehmenskontext und strukturierte Dokumentation integriert und dem Bediener alles an dem Ort präsentiert, an dem es relevant ist.

Die Terminologie ist wichtig. Ein klassisches HMI ist eine Bedien- und Überwachungsschnittstelle – es zeigt den Maschinenzustand an und akzeptiert Bedienereingaben. Ein Manufacturing Execution System (MES) ist auf einer höheren Organisationsebene angesiedelt und verwaltet Aufträge und Produktionsdaten maschinen- und linienübergreifend. An der Maschine selbst sitzt ein Maschineninformationssystem (MIS) im Sinne dieses eBooks: Es ist die integrierte Ansicht, die jede Art von Informationen über diese spezifische Maschine – Sensorzustände, aktuelle Reihenfolge, Handbücher, Schaltpläne, Alarmhistorie, Softwareversionen, Konformitätserklärungen – in eine navigierbare Raumoberfläche bringt.

Es erweitert die Informationsrolle eines HMI, schließt aber nicht notwendigerweise die Steuerungsrolle ein: Ein Maschineninformationssystem kann rein schreibgeschützt sein, was in vielen Fällen die einfachere und sicherere Wahl ist. Die Gründe: weniger Angriffsflächen unter den Cybersicherheitsanforderungen, ein geringerer Zertifizierungs- und Dokumentationsumfang und eine Haltung, die Bedienerinformationen, Wartungsunterstützung und Schulungsworkflows sauber abbildet.

Definition des Maschineninformationssystems

Ein Hinweis zur Terminologie: Maschinelles Informationssystem (MIS) im Sinne der Asset-Level-Begriffe in diesem eBook ist ein Begriff, den wir vorschlagen und nicht eine etablierte Branchenkategorie. Traditionelle HMIs konzentrieren sich auf Maschinensteuerung und Bedienerinteraktion, MES-Plattformen verwalten Produktion und Workflow auf Unternehmensebene und Asset Lifecycle Information Management-Systeme verwalten Engineering-, Dokumentations- und Lebenszyklusdaten. Jedes der beiden Systeme adressiert einen Teil des Informationsbedarfs des Bedieners, beschreibt jedoch nicht vollständig die integrierte, maschinenspezifische Ansicht, die über eine räumliche 3D Schnittstelle dargestellt wird.

Unter dem Begriff Maschineninformationssystem wird hier die fehlende Schicht verstanden: eine einheitliche Informationsfläche auf Maschinenebene, die Betriebszustand, Unternehmenskontext und strukturierte Dokumentation zu einem einzigen räumlichen Erlebnis für den Bediener vereint.

Ein gebräuchliches Einsatzbeispiel ist die Fehlerdiagnose.

• In einem traditionellen HMI sieht ein Bediener typischerweise einen Fehlercode und eine Textnachricht und konsultiert dann ein separates Handbuch, um den entsprechenden Abschnitt nachzuschlagen.
• In einem stärker integrierten HMI kann der Bediener auf die betroffene Komponente in der 3D Ansicht klicken und der Betrachter kann den aktuellen Signalzustand, den aktiven Produktionsauftrag von MES, die relevante Wartungshistorie und den passenden Abschnitt des digitalen Handbuchs anzeigen – alles mit derselben Komponenten-ID, die in der GLB-Datei oder im Szenendiagramm vorhanden ist.

Der Wert dieses Ansatzes geht weit über die Fehlerbehandlung hinaus.

Vier operative Vorteile zeigen sich durchgängig in Projekten, die ein Maschineninformationssystem in den Mittelpunkt des Bedienerlebnisses stellen:

Schnellere Fehlererkennung und Reaktion: Industrielle Maschinen enthalten oft Hunderte von Sensoren, Antrieben und Komponenten mit jeweils eigener Kennung in einem flachen Namensraum. Eine symbolische Meldung wie „Fehler des Sensors BG2-S147“ erfordert, dass der Bediener von einer abstrakten Kennung an einen physischen Ort übersetzt. Derselbe Fehler, der in der 3D Ansicht gezeigt wird – der betroffene Sensor, der auf der tatsächlichen Maschinengeometrie hervorgehoben ist – eliminiert den Übersetzungsschritt. Bei komplexen Maschinen oder bei Personal, das nicht täglich mit dem System arbeitet, ist das der Unterschied zwischen einer fünfminütigen Suche und einer sofortigen Reaktion.

Einheitlicher operativer Kontext: Wenn MES-Daten der 3D Szene überlagert werden, sieht der Bediener nicht nur, ob eine Maschine läuft, sondern auch, wie sie sich im Verhältnis zum aktiven Auftrag, der Sollzykluszeit und den aktuellen KPIs verhält. Wartungs- und Qualitätsinformationen werden an der Komponente angezeigt, auf die sie sich beziehen, nicht in einem separaten Dashboard. Das ist es, was ein Maschineninformationssystem liefert, wenn es im räumlichen Kontext und nicht in Tabellen und Listen geerdet ist, und es ist der praktische Grund, warum der Begriff für das, was diese Architektur produziert, genauer ist als „3D HMI“.

Reduzierte Abhängigkeit von Fachkompetenz: Nicht jeder Bediener hat das tiefe Wissen des Herstellers über jede Komponente. Mit Dokumentation, Sensorzuständen und Betriebsanweisungen, die aus derselben 3D Ansicht zugänglich sind, können weniger erfahrene Mitarbeiter Diagnosen und Routineeingriffe in erster Linie durchführen, die zuvor einen leitenden Techniker oder einen Serviceanruf erforderten. Dies ist in Branchen, in denen die Verfügbarkeit von Fachkräften eingeschränkt ist, immer wichtiger und macht Schichtübergaben, Urlaubsdeckung und Wochenendbetrieb robuster. Der Remote-Support profitiert umgekehrt: Der Servicetechniker des Herstellers sieht den gleichen 3D Kontext wie der Bediener vor Ort und kann über einen Videoanruf oder eine gemeinsame Sitzung präzise, räumlich verankerte Anweisungen geben.

Kontinuierliche betriebliche Wissenserfassung: Dies ist eine oft übersehene Rolle des Maschineninformationssystems. Der mitgelieferte Dokumentationssatz ist notwendigerweise unvollständig – er kann nicht jede Fehlerkonstellation, jeden Workaround, der sich als effektiv erwiesen hat, jedes Ursache-Lösungs-Paar, das Wartungspersonal über Jahre hinweg entdeckt, antizipieren. Wenn Bediener und Techniker Beobachtungen direkt an die betroffene Komponente in der 3D Szene anhängen können – eine Fehlerbeschreibung, die diagnostizierte Ursache, die angewendete Auflösung, die ausgetauschten Teile, Fotos oder kurze Notizen – wird das System zum Langzeitprotokoll, wie sich diese spezifische Anlage tatsächlich verhält. Über die Lebensdauer der Maschine sammelt sich diese zu einer strukturierten Fehler- und Lösungshistorie an, die an denselben Komponenten-IDs verankert ist wie die Originaldokumentation des Herstellers. Das Ergebnis ist eine Grundlage für einen wissensbasierten Betrieb des Assets: Schichtübergaben können auf reale frühere Vorfälle verweisen, weniger erfahrene Mitarbeiter erben die Diagnoseerfahrung ihrer Vorgänger und (wie in Teil 2 diskutiert) KI-basierte Diagnosetools können ihre Antworten in der tatsächlichen Geschichte dieser Anlage gründen, nicht nur im Herstellerhandbuch.

Die technischen Komponenten für diese Art der Integration sind heute verfügbar: WebSocket-Streams für Live-Signale, REST oder OPC UA für MES-Kontext, strukturierte digitale Dokumentation, die an Komponentenkennungen gebunden ist, und ein 3D Viewer (Unity native, WebGL oder ein browserbasierter Stack wie der realvirtual.io Web Viewer, mit einer öffentlichen Demo unter web.realvirtual.io/demo), der die kombinierte Ansicht wiedergibt. Die übrigen Arbeiten für Integratoren sind weitgehend architektonischer und nicht technologischer Natur.

5. Architekturmuster für Integratoren

Best Practices für den Aufbau eines Maschineninformationssystems

Behandlung der 3D Szene als Quelle geometrischer und identifizierbarer Wahrheit. Komponenten-IDs, kinematische Struktur und Metadaten können in der Szenedatei gespeichert werden (z. B. als Erweiterungsdaten in einem GLB oder in Unity Prefab Metadaten). Andere Systeme referenzieren diese IDs dann, ohne sie neu zu definieren. Dieser Ansatz ermöglicht einen Klick in die 3D Ansicht, um konsistent in ein Signal, einen MES-Datensatz und einen manuellen Abschnitt aufzulösen. Der folgende Screenshot zeigt dieses Muster auf einer realen Verpackungslinie: Der Unity Editor ist die Authoring-Umgebung, in die der Maschinenbauer CAD importiert, die Kinematik und Komponentenhierarchie definiert, das Sensor- und Antriebsverhalten konfiguriert und die strukturierten Metadaten anfügt, die mit jedem GameObject für den Rest der Lebensdauer der Maschine reisen.

Im Inspektor rechts wird das räumliche Indexmuster anhand der Laufzeitmetadaten und der laufzeitinteragierbaren Komponenten in der Praxis umgesetzt: Die Komponenten-ID lebt auf dem GameObject, nicht in einer externen Mapping-Tabelle, sodass der Export nach GLB die Kennung mit der Geometrie trägt. Die virtuelle Inbetriebnahme erfolgt in derselben Szene – Antriebs- und Sensormodelle aus dem realvirtuellen Kern reagieren auf die angeschlossene SPS und trainieren die Kinematik und das Signalmapping, bevor die physische Maschine existiert. Sobald die Szene abgemeldet ist, werden dieselben erstellten Inhalte exportiert wie die GLB, die zur Laufzeit geliefert wird, ohne separaten nachgelagerten Remodellierungsschritt.

Verwendung dünner, zweckspezifischer Adapter für jede Datenschicht. Ein WebSocket-Adapter für Signale, ein REST- oder OPC-UA-Client für MES, ein Dokumentendienst, der Handbücher und Schaltpläne nach Komponenten-ID belichtet. Jeder Adapter ist für eine Quelle zuständig. Toolkits wie realvirtual.io strukturieren die Signal- und Szenenseite entlang dieser Linien; das gleiche Muster kann auf MES und Dokumentation erweitert werden.

Version des Maschineninformationssystems neben der Software. Werden Unterlagen digital bereitgestellt, müssen die EU-Konformitätserklärung und die Gebrauchsanweisungen gemäß der Maschinenverordnung während der gesamten Lebensdauer der Maschine zugänglich bleiben, auch über Softwareupdates hinweg. Die pragmatische Antwort ist breiter als die Dokumentation allein: Das gesamte Maschineninformationssystem – die 3D Szene, Signalmappings, Komponentenmetadaten, strukturierte Dokumentation und das erfasste Betriebswissen, das sich über Jahre ansammelt – ist selbst ein versioniertes Artefakt, das an eine bestimmte Maschinenseriennummer und Softwarefreigabe gebunden ist. Die Eigenschaften, die hier benötigt werden, sind diejenigen, die die Softwareentwicklung in den letzten zwei Jahrzehnten bereits gelöst hat: unveränderliche historische Zustände, die jede vergangene Lieferung exakt rekonstruieren lassen, signierte Tags, die das Inverkehrbringen für regulatorische Zwecke markieren, Zweigstellen für Maschinenvarianten und kundenspezifische Konfigurationen und verteilte Klone, die jeden einzelnen Werkzeughersteller über einen Zeitraum von mehr als zehn Jahren überleben – typischerweise die tatsächliche Lebensdauer von Industriemaschinen, nicht das gesetzliche Minimum. Git, das auf der Ebene eines ganzen Maschinenpakets und nicht nur auf Quellcode angewendet wird, passt erstaunlich gut zu diesem Eigenschaftspaket. Systeme wie Gitea (die Archivschicht in der realvirtua.io Referenzarchitektur in Abschnitt 6) entwickeln sich zu einem natürlichen Zustell- und Archivformat für industrielle Maschinenpakete, wobei Versionierungsmuster, die in der Softwareentwicklung lasttragend waren, sich direkt auf die Einschränkungen der traditionellen Maschinenzustellung übertragen.

Belichtung des Dokumentationssatzes über eine strukturierte API. Ein Dokumentendienst, der den relevanten manuellen Abschnitt als Antwort auf eine Komponenten-ID und einen Fehlercode zurückgibt, ist für einen menschlichen Bediener nützlich. Derselbe strukturierte Zugriff unterstützt auch Anwendungsfälle, die in Teil 2 diskutiert werden, in denen KI-Tools ihre Ausgabe in der eigentlichen Dokumentation des Herstellers gründen können, anstatt sich ausschließlich auf Schulungsdaten zu verlassen.

6. Eine Referenzarchitektur

Die bisher eingeführten Elemente – die vier Datenschichten, das Maschineninformationssystemkonzept und die Architekturmuster oben – verbinden sich zu einer Referenzarchitektur, die Integratoren anpassen können. Das nachstehende Diagramm zeigt den realvirtua.iol-Referenzstapel — Authoring-Umgebung, Gitea-Archiv, Maschineninformationssystemlaufzeit und Anlagenanbindung — als eine konkrete Instanz des Musters. Die gleiche generelle Aufteilung zwischen Authoring und Delivery kann mit verschiedenen spezifischen Tools implementiert werden.

• Auf der Autorenseite verwendet Unity Editor CAD- und 3D-Assets aus dem Unity Asset Manager und Maschinenmetadaten aus Lieferanten-AAS-Quellen (Siemens, Festo, ABB) und dem PDM-System und erstellt Metadaten-, Signal- und Dokumentationsmappings für den realvirtual.io Core. Unity wird dann verwendet, um das importierte Maschinen-CAD-Modell einzurichten, indem Materialien, kinematisches Verhalten und Bewegungseinschränkungen auf einzelne Komponenten angewendet werden. Dadurch wird die statische Geometrie in ein vollständig interaktives und physikalisch realistisches 3D Maschinenmodell verwandelt, das Benutzer in Echtzeit navigieren und bedienen können.

Das Export-Bundle — 3D Machine Model (GLB), AAS-Daten, Dokumentation und die unterzeichnete Konformitätserklärung — wird in einem Gitea-Repository als getaggte Freigabe archiviert, die als das gemäß der Maschinenverordnung (EU) 2023/1230 vorgeschriebene 10-Jahres-Archiv vorgesehen ist.

• Auf der Auslieferungsseite wird das Maschineninformationssystem Runtime – realvirtual.io WEB auf Three.js, TypeScript, AGPL-lizenziert und selbst hostbar – aus dem Gitea-Archiv bereitgestellt und über rv Connect (Live-Signale), InfluxDB (Zeitreihe) und die SPS-Schnittstellen der Maschine mit der laufenden Anlage verbunden.
• Der realvirtual.io-Kern – gemeinsames Laufwerk, Sensor und kinematisches Verhalten – existiert sowohl in der Authoring- als auch in der Laufzeitumgebung: als Unity-Komponente während der Authoring- und virtuellen Inbetriebnahme und als Three.js-Komponente zur Laufzeit.
• Das bestehende Automatisierungssystem – SPS, Antriebe, Sensoren, Roboter, MES – ist am unteren Rand des Stapels unverändert. Darüber sitzt die Signalschicht und die MES-Schicht, die die meisten Integratoren bereits aufbauen. Daneben erfüllt der Dokumentationsservice, strukturiert nach Bauteil-ID und Fehlercode, sowohl die regulatorische Archivanforderung als auch den Bedarf des Bedieners an schnellem, aussagekräftigem Referenzmaterial an der Maschine.

Klicken Sie hier für Teil 2, wo wir besprechen, wie eine MCP- und Agentenschicht darauf passt, ohne die zugrunde liegende Architektur zu ändern.