Die Argumentationsebene: LLMs, Agenten und MCP

Ein praktischer Leitfaden für Systemintegratoren, OEMs und Automatisierungstechniker — Teil 2

In Zusammenarbeit mit Thomas Strigl, CEO, realvirtual.io

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

Klicken Sie hier für Teil 1 dieser E-Book-Reihe, Von der Visualisierung zur Aktion: Unity, Maschineninformationssysteme, KI-Agenten und der industrielle digitale Zwilling.

In Teil 1 dieser E-Book-Reihe wurde das architektonische Fundament eines modernen Maschineninformationssystems vorgestellt: die Konvergenz von Live-Maschinensignalen, MES-Kontext, strukturierter Dokumentation und räumlichen 3D-Schnittstellen in einer einzigen Bedienoberfläche. Es wurde auch untersucht, wie die neue EU-Maschinenverordnung und neue Standards wie die Asset Administration Shell (AAS) die Maschinendokumentation in Richtung strukturierter, maschinenlesbarer Formate vorantreiben. Dieselben Grundlagen — komponentenverknüpfte Daten, versionierte Dokumentation und kontextualisierter Maschinenzustand — machen KI-Agenten und große Sprachmodelle in industriellen Umgebungen nutzbar.

Dieser zweite und abschließende Teil dieser E-Book-Reihe baut auf dieser Architektur auf und untersucht die „Grundschicht“: wie KI-Systeme auf einen zuverlässigen Betriebs- und Dokumentationskontext zugreifen können und wie Protokolle wie MCP in den Stack von Maschineninformationssystemen passen.

Das Erdungsproblem

Ein üblicher erster Ansatz zur Integration großer Sprachmodelle in industrielle Kontexte besteht darin, einem bestehenden System — einer Website, einem Support-Portal oder einem HMI — einen Chatbot hinzuzufügen. In der Praxis hat dieser Ansatz Einschränkungen.

Ein Sprachmodell allein hat keinen Zugriff auf den Live-Status der Maschine, den aktuellen Produktionsauftrag oder die herstellerspezifische Dokumentation. Ohne diesen Kontext basieren die Antworten auf Trainingsdaten, die generisch und möglicherweise veraltet sein können und wahrscheinlich nicht die jeweilige Maschine beinhalten.

Dies wird allgemein als Erdungsproblem bezeichnet. Damit ein LLM im industriellen Kontext nützliche Ergebnisse liefern kann, benötigt es in der Regel einen strukturierten Zugriff auf drei Dinge: den Live-Status der Maschine, den relevanten Unternehmenskontext und die Dokumentation des Herstellers.

Die in Teil 1 beschriebene Vierschichtarchitektur entspricht dieser Anforderung einigermaßen. Signale geben den aktuellen Status an. MES bietet den betrieblichen Kontext. Die Dokumentation bietet maßgebliches Referenzmaterial. Die 3D-Szene bietet den räumlichen Rahmen, in dem all dies dargestellt werden kann.

MCP als Integrationsmuster

Das Model Context Protocol (MCP) ist ein offener Standard, der definiert, wie Tools und Datenquellen auf konsistente Weise Sprachmodellen zugänglich gemacht werden können. Es gibt an, wie ein Client eine Verbindung zu einem Server herstellt, wie der Server seine Funktionen ankündigt und wie das Modell sie aufruft. Obwohl MCP ursprünglich für allgemeine Entwicklertools konzipiert wurde, lässt sich das Muster ziemlich gut auf die industrielle Integration übertragen, wo das zugrunde liegende Problem — die Bereitstellung eines konsistenten Zugriffs auf eine heterogene Gruppe von zugrunde liegenden Systemen — ähnlich ist.

Die meisten Anlagen kombinieren SPS verschiedener Anbieter, ein MES-System, eine Dokumentenverwaltungsplattform und einen Historiker. Ohne eine Standardebene muss jeder neue Client einzeln in jedes dieser Systeme integriert werden. Mit MCP kann jedes zugrunde liegende System einmal in einen MCP-Server eingebunden und über eine einheitliche Schnittstelle bereitgestellt werden, die jeder konforme Client verwenden kann.

Für einen industriellen digitalen Zwilling sind drei Kategorien von MCP-Servern besonders relevant:

• Ein Maschinenzustandsserver, der Live-Signalwerte, Alarmzustände, Antriebspositionen und aktuelle Historie anzeigt — unterstützt durch die vorhandene Signalschicht (OPC UA, Beckhoff ADS, MQTT, S7 oder eine WebSocket-basierte Streaming-Schicht).
• Ein MES-Server, der Bestellungen, Batches, KPIs und Qualitätsaufzeichnungen verfügbar macht — unterstützt durch REST-APIs, Message-Broker oder direkte Datenbankabfragen.
• Ein Dokumentationsserver, auf dem die strukturierte digitale Dokumentation — Betriebsanleitungen, Schaltpläne, Konformitätserklärungen, Softwareversionen, Wartungsverfahren — nach Komponenten-ID, Fehlercode oder natürlicher Sprache durchsuchbar und abrufbar ist.

Ein LLM, das mit diesen drei Servern verbunden ist, hat eine Grundlage für geerdete Antworten. Eine Frage wie „Warum hat Linie 3 angehalten?“ kann beantwortet werden, indem der Alarmstatus gelesen, die betroffene Komponente identifiziert, der entsprechende Abschnitt zur Fehlerbehebung aus dem Handbuch abgerufen und das Ergebnis mit der hervorgehobenen betroffenen Komponente im 3D-HMI dargestellt wird. Die Ausgabe basiert auf tatsächlichen Systemen und nicht auf den Trainingsdaten des Modells.

Die in Teil 1 dieser E-Book-Reihe beschriebene Referenzarchitektur aus Abschnitt 6 geht direkt in diese Schicht über. Die dort beschriebenen Signal-, MES- und Dokumentationsdienste werden von MCP-Servern umschlossen, die sie über eine konsistente Schnittstelle verfügbar machen. Eine LLM- oder Agentenlaufzeit, die je nach Datenrichtlinie des Kunden lokal, auf einem Edge-Server oder in einer privaten Cloud ausgeführt wird, stellt eine Verbindung zu diesen Servern her. Die daraus resultierenden Antworten basieren auf dem aktuellen Stand, dem aktuellen Kontext und der maßgeblichen Dokumentation.

Das 3D-HMI befindet sich an der Spitze des Stacks und dient zwei Verbrauchern: dem Bediener und allen KI-basierten Tools. KI-Tools verwenden es sowohl als Präsentationsfläche (Hervorheben von Komponenten, die für eine Antwort relevant sind) als auch als Bestätigungsfläche (Anzeige der vorgeschlagenen Maßnahmen zur menschlichen Überprüfung). Das HMI wurde in Unity erstellt und deckt den CAD-Import, die Kinematik, die Signalzuordnung und die Komponentenmetadaten ab, die die Runtime verwenden wird. Es wird entweder als Unity-natives Build für Desktop, Tablet, AR/VR oder Industrie-PC oder als browserbasiertes 3D-HMI bereitgestellt, das auf Three.js für WebGL-Bereitstellungen basiert. Dieselbe von Unity erstellte Szenendatei, die mit konsistenten Komponenten-IDs nach GLB exportiert wurde, dient beiden Lieferzielen.

Die offene C#-Umgebung von Unity unterstützt sowohl das direkte Hosten von Inferenzen — über Sentis als auch ONNX, wie im E-Book Design, Simulate, Deploy beschrieben: Warum Unity für Industrial Digital Twins wichtig ist — und als Frontend für externe Laufzeiten fungiert. Bei den meisten Integratorprojekten ist es einfacher, die Agentenlaufzeit vom HMI zu trennen, wobei MCP die Integrationsgrenze darstellt.

Dokumentation und Erdung

Es gibt eine bemerkenswerte Überschneidung zwischen der regulatorischen Ausrichtung und den technischen Anforderungen für eine geerdete LLM-Produktion.

In der Vergangenheit war Dokumentation ein erfüllbarer Kostenfaktor — sie wurde erstellt, weil sie benötigt wird, und relativ selten konsultiert. Gemäß der Verordnung (EU) 2023/1230 kann die Dokumentation digital geliefert werden. Wenn dies der Fall ist, muss sie strukturiert und online sein und über einen Lebenszyklus von mindestens 10 Jahren oder über die gesamte Lebensdauer der Maschine — in der Regel letztere, aufbewahrt werden, da Industriemaschinen selten bis zum gesetzlich vorgeschriebenen Minimum ausgemustert werden. Sobald eine Dokumentation in dieser Form vorliegt, hat sie auch Eigenschaften, die sie als Grundlage für Sprachmodelle geeignet machen: Sie ist strukturiert, anhand einer Komponente oder eines Fehlercodes identifizierbar und sie ist vom Hersteller autorisiert.

Ein LLM, das auf der tatsächlich vom Hersteller gelieferten Dokumentation basiert, führt mit geringerer Wahrscheinlichkeit zu ungenauen Verfahren oder erfundenen Artikelnummern, da die Antworten auf bestimmte Abschnitte der Dokumentation zurückgeführt werden können. Dies kann auch für die Überprüfbarkeit und die Integration mit den Protokollierungs- und Entscheidungsaufzeichnungspflichten relevant sein, die die Verordnung für sicherheitsrelevante Software einführt.

Für Integratoren besteht die praktische Beobachtung darin, dass bei der Vorbereitung einer strukturierten digitalen Dokumentation — die unabhängig davon erforderlich sein wird — auch ein Artefakt entsteht, das als Grundlage für LLM-basierte Tools verwendet werden kann. Die beiden Bemühungen überschneiden sich, anstatt um separate Budgets zu konkurrieren.

LLMs als Entwicklungsbeschleuniger

Senkung der Kosten für Integrationsarbeiten

In der bisherigen Diskussion wurden LLMs als Verbraucher digitaler Zwillingsdaten behandelt — Tools, die den Live-Status lesen, Dokumentationen abfragen und Bedienern antworten. Es gibt eine zweite Rolle mit direkteren Konsequenzen für die Integratorökonomie: LLMs als Beschleuniger bei der Entwicklung des Zwillings selbst.

Der Aufbau eines integrierten digitalen Zwillings erfordert einen erheblichen Arbeitsaufwand, der technisch einfach, aber zeitaufwändig ist. Adaptercode zwischen der Signalschicht und der 3D-Szene. REST- oder OPC UA-Clients für das MES. Zuordnen von Tabellen zwischen SPS-Variablen und Komponenten-IDs. Projektspezifische Diagramme, Dashboards und kleine UI-Komponenten im HMI. Schemaarbeit, um Dokumentationsabschnitte an Komponenten in der Szene auszurichten. Keine dieser Aufgaben ist besonders schwierig; sie sind manuell, wiederholen sich und sind projektspezifisch.

LLM-gestützte Codierungstools können den Aufwand reduzieren, der für diese Art von Arbeit erforderlich ist. Sie können Adapter für eine neue MES-API generieren, Chart-Komponenten zusammenstellen, Mappings zwischen Signaltabellen und kinematischen Hierarchien erstellen. Der Effekt ist nicht, dass Integratoren aufhören, Code zu schreiben, sondern dass die routinemäßige Integrationsarbeit weniger Zeit in Anspruch nimmt. Dies ist in industriellen Kontexten wichtig, da der lange Schwanz kleiner, projektspezifischer Glue-Codes in der Vergangenheit einer der Hauptgründe war, warum Integrationsprojekte teuer sind.

Warum standardisierte Schnittstellen wichtig sind

Dieser Effekt verstärkt sich, wenn die zugrunde liegenden Schnittstellen standardisiert werden. MCP-Server, die Maschinenstatus, MES-Daten und Dokumentation offenlegen, sind einfachere Ziele für LLM-gestützte Entwicklungen als maßgeschneiderte Ad-hoc-APIs. Die Kombination aus standardisierten Schnittstellen und LLM-gestützter Entwicklung senkt die Schwelle für den Aufbau integrierter digitaler Zwillinge.

Die Grenzen von LLM-generiertem Code

Zwei Einschränkungen sind bemerkenswert. LLM-generierter Code ist ein Entwurf, kein Ergebnis. Für sicherheitsrelevanten Code oder Steuersystemcode gelten dieselben Überprüfungs- und Validierungsprozesse wie für jeden anderen Code. Und die Beschleunigung bezieht sich in erster Linie auf Integrations- und Visualisierungsarbeiten, nicht auf die zugrunde liegende Steuerlogik, für die nach wie vor die Automatisierungstechniker verantwortlich sind, die etablierte Tools verwenden.

Trennen der Erstellung von der Laufzeitbereitstellung

Ein nützliches Architekturmuster in diesem Zusammenhang besteht darin, die Authoring-Umgebung vom gelieferten Artefakt zu trennen. Die Authoring-Umgebung ist Unity — die etablierte Plattform für industrielle digitale Zwillinge. Sie wird als Editor verwendet, in dem der Maschinenbauer CAD importiert, Kinematik definiert, Verhaltensmodelle konfiguriert und Dokumentation mit Komponenten verknüpft. Unity bietet die umfassende Werkzeugausstattung, die CAD-Import-Pipeline, die kinematische und physikalische Unterstützung sowie die plattformübergreifenden Build-Ziele, die Industrieprojekte benötigen. Das gelieferte Artefakt läuft jedoch während der gesamten Lebensdauer der Maschine in der Kundenumgebung und profitiert davon, dass es offen und selbst hostbar ist: ein browserbasierter Viewer, der auf Standard-Webtechnologie (Three.js, TypeScript) basiert und ein Standard-Szenenformat (GLB) verwendet. Der realvirtual.io-Webviewer mit seinem Unity-basierten Authoring-Stack, der eine AGPL-lizenzierte Open-Source-Web-Runtime speist, ist ein Beispiel für dieses Muster, das heute in Produktion ist.

Die umfassenderen Auswirkungen auf Industrie 4.0

Zusammengenommen haben diese Auswirkungen eine breitere Auswirkung auf Industrie 4.0. Ein häufiges Hindernis für Integrationsprojekte waren die Kosten für das Zusammenfügen heterogener Systeme. Wenn diese Kosten sinken, wird der digitale Zwilling als Integrationsplattform attraktiver — nicht nur als Visualisierungsprodukt, sondern als Ebene, auf der Signale, Unternehmensdaten, Dokumentation und Visualisierung zusammenlaufen. Für Systemintegratoren ist dies die dauerhaftere Rolle des digitalen Zwillings: Er ist weniger ein Ergebnis an sich, sondern eher der Ort, an dem sich alles andere trifft.

Agenten in der Werkstatt — Ein Spektrum

Der Begriff „Agent“ umfasst eine Reihe von Verhaltensweisen mit ganz unterschiedlichen Risikoprofilen. Es ist nützlich, genau zu sagen, was gemeint ist.

• Am stärksten eingeschränkt sind Diagnosetools, die nur gelesen werden können. Sie beobachten den Zustand, lesen Unterlagen und beantworten Fragen. Sie schreiben nicht in Steuerungssysteme. Ein Bediener fragt, warum eine Leitung gestoppt wurde; das System liest den Alarmstatus, schlägt den Code im Handbuch nach und erklärt es. Dies ist ein vernünftiger Ausgangspunkt und für eine Reihe von Anwendungsfällen auch ein vernünftiger Endpunkt.
• In der Mitte befinden sich Beratungsinstrumente. Sie beobachten den Zustand und schlagen Maßnahmen vor — eine Sollwertänderung, eine Wartungsaufgabe, eine Parameteranpassung —, führen sie aber nicht aus. Der Betreiber bestätigt oder lehnt jeden Vorschlag ab. Das 3D-HMI kann als Bestätigungsfläche dienen und die betroffene Komponente und die vorgeschlagene Änderung des räumlichen Kontextes anzeigen, bevor ein Schreibvorgang erfolgt. Dieses Muster bewahrt das menschliche Urteilsvermögen in der Entscheidungsschleife und nutzt gleichzeitig KI-Unterstützung für die Diagnose.
• Am wenigsten eingeschränkt sind handlungsorientierte Systeme, die in SPS schreiben, Rezepte ändern oder Bestellungen versenden, ohne dass eine menschliche Genehmigung vor jeder Aktion erforderlich ist. Dies ist in einigen Zusammenhängen technisch machbar, bringt aber zusätzliche Überlegungen im Rahmen der neuen Maschinenverordnung mit sich. Cybersicherheit ist heute eine grundlegende Gesundheits- und Sicherheitsanforderung gemäß Anhang III, und KI-gestützte Sicherheitsfunktionen fallen ausdrücklich in den Geltungsbereich der Liste der Hochrisikemaschinen der Verordnung, weshalb eine strengere Konformitätsbewertung erforderlich ist. Jeder Pfad, der es einem LLM-gesteuerten System ermöglicht, in ein Steuerungssystem zu schreiben, ist auch ein potenzieller Angriffspfad. Solche Systeme müssen in der Regel mit der gleichen Sorgfalt entworfen werden wie alle anderen Steuerungssystemkomponenten mit Schreibzugriff, einschließlich der Protokollierungs- und Datenaufzeichnungspflichten, die die Verordnung für sicherheitsrelevante Software vorsieht.

In frühen Projekten ist es üblich, standardmäßig schreibgeschützt zu sein, auf Beratung mit ausdrücklicher Bestätigung durch den Bediener auszudehnen und alle Funktionen zum Ausführen von Maßnahmen als Steuerungssystemkomponente zu behandeln, die derselben Überprüfung und Validierung unterliegt wie SPS-Code.

Ein praktischer Ausgangspunkt für Integratoren

Für Integratoren, die überlegen, wo sie anfangen sollen, funktioniert ein schrittweiser Ansatz in der Regel besser als ein ehrgeiziger.

Eine erste praktische Implementierung könnte Folgendes beinhalten:

• Verwenden eines vorhandenen Maschinenprojekts: Beginnen Sie mit einer Maschine, die bereits über ein 3D-HMI und ein strukturiertes Dokumentationspaket verfügt, das gemäß der Verordnung (EU) 2023/1230 erstellt wird.
• Bereitstellung der Dokumentation über einen MCP-Server: Verpacken Sie den Dokumentationssatz in einen einzigen MCP-Server, der das Abrufen nach Komponenten-ID unterstützt.
• Verbindung des 3D-HMI mit Dokumentationsdiensten: Konfigurieren Sie das vorhandene 3D-HMI so, dass bei Auswahl einer Komponente der entsprechende manuelle Abschnitt automatisch abgerufen wird.
• Hinzufügen einer fixierten KI-Schnittstelle: Führen Sie neben der 3D-Ansicht ein Chat-Panel ein, indem Sie ein Allzweck-LLM verwenden, das auf dem MCP-Server für die Dokumentation basiert.

Erwartete Ergebnisse

Das Ergebnis ist eine Maschine, bei der ein Bediener eine Frage stellen kann, eine Antwort erhalten kann, in der die Dokumentation des Herstellers zitiert wird, und die entsprechende Komponente in der 3D-Ansicht hervorgehoben sehen kann. Es gibt keine Kontrollzustände, keine autonomen Aktionen und keine neue Automatisierungsinfrastruktur. Die Vorteile — weniger Support-Anfragen, bessere Erstbehebungsraten, leichterer Zugang zu Herstellerwissen — sind messbar und die Risiken sind begrenzt.

Für Integratoren, die sehen möchten, wie ein solches System in der Praxis aussehen kann, ist eine öffentliche Demonstration eines browserbasierten 3D-HMI, das Live-Signaldaten verarbeitet, unter web.realvirtual.io/demo verfügbar. Die zugrundeliegende Architektur — Unity als Authoring-Umgebung, ein offener Web-Stack für die Auslieferung und ein Standard-Versionskontrollsystem wie Gitea zur Speicherung des gelieferten Pakets über den regulatorischen Zehnjahreshorizont hinweg — ist ein Muster, das Integratoren übernehmen und an ihre eigenen Projekte anpassen können.

Von diesem Ausgangspunkt aus können schrittweise weitere Schritte hinzugefügt werden. Ein MCP-Server auf Signalebene ermöglicht Fragen zum Live-Status. Eine MES-Verbindung ermöglicht Fragen zu aktuellen Bestellungen. Beratungsempfehlungen mit Bestätigung durch den Bediener im 3D-HMI erweitern das System weiter, ohne das grundlegende Risikoprofil zu ändern. Jeder Schritt ist für sich allein testbar und reversibel.

Die Architektur, die sowohl Compliance als auch KI unterstützt

Das vorherige E-Book schloss mit der Beobachtung, dass digitale Zwillinge sowohl eine organisatorische als auch eine technische Investition sind — dass beispielsweise eine virtuelle Inbetriebnahme nur dann einen Mehrwert bietet, wenn die umliegenden Prozesse bereit sind, sich zu ändern. Eine ähnliche Beobachtung gilt hier.

Bei den Integratoren laufen jetzt zwei Zeitlinien zusammen. Die Maschinenverordnung ist seit 2023 bekannt, aber die praktische Vorbereitung auf den Geltungsbeginn am 20. Januar 2027 — neue Cybersicherheitsbestimmungen, die verpflichtend sind, und die jetzt explizite Option einer strukturierten digitalen Dokumentation mit Lebenszykluswartung — verlagert sich von der Planung zur Umsetzung. Parallel dazu sorgen KI-Tools für eine Nachfrage nach strukturierten, fundierten Daten. Diese können als separate Projekte behandelt werden, aber die zugrundeliegenden Arbeiten überschneiden sich erheblich. Die in Teil 1 beschriebene vierschichtige Architektur unterstützt sowohl den Operator als auch alle später hinzugefügten KI-Tools. Eine strukturierte digitale Dokumentation, die für die Einhaltung gesetzlicher Vorschriften erstellt wurde, ist auch als Grundlage nützlich. Das 3D-HMI kann als einheitliche Oberfläche für all diese dienen.

Die in Teil 1 beschriebenen betrieblichen Vorteile — schnellere Diagnose, geringere Fachkenntnisse, kontextualisierte Informationsbereitstellung, sinnvoller Fernsupport — gelten unabhängig vom regulatorischen Kontext. Integratoren außerhalb der EU oder die an Systemen arbeiten, die nicht unter die Maschinenverordnung fallen, profitieren von denselben betrieblichen Vorteilen aus derselben Architektur, ohne dass die regulatorische Frist als Zwangsfunktion gilt. Die Architektur stützt sich allein auf ihre praktischen Argumente; die Verordnung macht lediglich den Zeitplan für den europäischen Markt explizit.

Autonomer Betrieb ist nicht das geeignete erste Ergebnis. Ein realistischerer Ausgangspunkt ist eine Maschine, die ein Bediener abfragen kann, die ein Integrator unterstützen kann und die ein Hersteller über den regulatorischen Zeitraum von zehn Jahren auf dem Laufenden halten kann. Die Werkzeuge und Standards, die für den Bau einer solchen Maschine benötigt werden, sind bereits verfügbar, und der Großteil der Grundlage besteht aus Arbeiten, die Integratoren unabhängig davon erledigen müssen.