Die neueste Generation von LLMs (Large Language Models), auch als Foundation-Models bekannt, bietet leistungsstarke Funktionen, um komplexe Aufgaben zu lösen. Eine ihrer zentralen Fähigkeiten ist der Zugriff auf externe Datenquellen und deren Interpretation. Das Model Context Protocol (MCP) nutzt genau diese Stärke, indem es einen standardisierten, einheitlichen Zugriff auf unterschiedliche externe Systeme ermöglicht. Dadurch können Informationen effizient ausgetauscht oder externe Systeme direkt gesteuert werden.
Für technisch interessierte Leser:innen, insbesondere aus den Bereichen Künstliche Intelligenz und Industrie 4.0, wird dies am Beispiel eines Smarthomes veranschaulicht: Ein LLM soll verschiedene Geräte eines vernetzten Smarthomes steuern, deren Komponenten von unterschiedlichen Herstellern stammen, die alle MCP unterstützen. Das Modell muss die spezifischen Domains dieser Geräte erkennen – beispielsweise unterscheiden sich Begriffe wie “Helligkeit” bei einem RGB-Licht-Aktor von einem Lichtsensor erheblich. Hier zeigt sich eine zentrale Herausforderung: die semantische Abhängigkeit zwischen den Geräten muss korrekt interpretiert und harmonisiert werden, um präzise Entscheidungen zu ermöglichen.
Die Industrie hat solche Herausforderungen bereits in den Standard der Asset Administration Shell (AAS) integriert, um Konsistenz und semantische Interoperabilität zu gewährleisten – insbesondere bei langfristigen Anwendungen wie dem digitalen Zwilling. Während MCP auf Flexibilität und Geschwindigkeit setzt, zielt AAS auf strukturelle Stabilität und präzise Semantik. Beide Standards ermöglichen die Bereitstellung interoperabler Informationen, verfolgen jedoch unterschiedliche Ansätze.
In den folgenden Kapiteln werden AAS und MCP im Detail vorgestellt und verglichen. Dabei wird anhand eines praktischen Beispiels verdeutlicht, wie beide Technologien zusammenarbeiten können, um ihre individuellen Stärken zu kombinieren.
Die Asset Administration Shell (AAS) – Standard für digitale Zwillinge der Industrie 4.0
Das Konzept der AAS beschreibt eine standardisierte, digitale Repräsentation eines physischen Gegenstandes durch ein digitales Asset. Sie basiert auf einem IEC-konformen Metamodell und besteht aus folgenden Strukturelementen:
Struktur-Diagramm einer AAS:
Beschreibung der Struktur einer AAS:
| Element | Beschreibung |
|---|---|
| AAS | Die AAS selbst ist eine kontextbezogene Sicht auf ein Asset und seine Attribute. Attribute werden in Form von Submodellen beschrieben. Die kontextbezogene Schicht resultiert daraus, dass für verschiedene Anwendungszwecke ein unterschiedliches Set an Attributen relevant ist. |
| Asset | Das Asset ist die digitale Identität eines realen Gegenstandes. |
| Submodel | Ein Submodel kann eine beliebige Struktur aufweisen und ebenfalls auf andere AASen und Assets verweisen. Das Submodel selbst und alle Elemente haben immer eine SemanticId, welche den angegebenen Wert genauer beschreibt. |
| Submodel-Element | Ein Submodel selbst besteht aus einer beliebigen Anzahl an Submodel-Elementen. Diese Elemente können einfache Werte sein, oder komplexe Objekte mit beliebiger Tiefe. |
Der AAS-Standard basiert auf einem vorgeschriebenen Metamodell, das die Struktur sowie die semantische Beschreibung von Submodel-Elementen exakt definiert. Diese semantische Beschreibung ermöglicht die präzise Spezifikation jedes Elements eines Submodells, wodurch sichergestellt wird, dass die Werte korrekt interpretiert werden. Die Semantik kann entweder auf bestehenden Standards wie ECLASS basieren oder spezifisch für einzelne Submodelle definiert werden. Damit schafft der AAS-Standard eine Art “Public-Language-Layer”, der unternehmensspezifische Domains innerhalb der Industrie miteinander verbindet. Das Übersetzen der Semantik erfolgt im Prozess der Datenbereitstellung: Der Anbieter erstellt die Submodelle, indem er die Daten seiner Domain in die des Submodels übersetzt, während der Konsument sie beim Zugriff entsprechend wieder in seine eigene Domain übersetzt.
Zusätzlich spezifiziert der Standard den Zugriff auf die AAS durch eine REST-API und die AASX-Dateiformatdarstellung. Die REST-API wird genutzt, um auf die Bestandteile der AAS flexibel zuzugreifen. Sie deckt verschiedenste Anwendungsfälle ab, was sie einerseits mächtig, andererseits umfangreich und komplex macht. Die API ermöglicht mehrere Betriebsarten:
- Ein Asset selbst kann einen Endpunkt bereitstellen, über den es seine AAS und Submodelle präsentiert.
- Zentrale Systeme können zahlreiche AASen samt Submodellen bündeln und bereitstellen.
- AASen und Submodelle können auf unterschiedliche Systeme aufgeteilt werden – beispielsweise ein System für die AAS und ein anderes für die Submodelle.
- Mithilfe eines Registry-Teils der API können Submodelle und AASen auf verschiedene Systeme verteilt und über ein sogenanntes “Lookup” auffindbar gemacht werden.
Diese Flexibilität macht die AAS vielseitig, bringt jedoch zusätzliche Komplexität mit sich, da ein tiefes Verständnis der zugrundeliegenden Struktur und Historie erforderlich ist.
Inzwischen existieren zahlreiche Submodelle für die unterschiedlichsten Anwendungsbereiche. Neutrale Submodelle decken allgemeine Eigenschaften realer Industrieprodukte ab, wie z. B. Typenschilder (Digital Nameplates), technische Daten (Technical Data) oder Benutzerdokumentationen (Handover Documentation). Darüber hinaus gibt es hoch spezialisierte, branchenspezifische Submodelle, beispielsweise für Energieanlagen oder Kraftwerke. Allerdings führen semantische Überschneidungen und die zunehmende Anzahl solcher Modelle dazu, dass der AAS-Standard komplexer und für Neueinsteiger teils überfordernd wirken kann.
Das Model Context Protocol – Einfach, offen, KI-orientiert
Das Model Context Protocol (MCP) bietet eine flexible und leichtgewichtige Lösung für die Integration und Verarbeitung von Daten in KI-basierten Systemen. Es erfordert keine aufwendige semantische Modellierung und kann in kurzer Zeit produktiv eingesetzt werden, wodurch Entwicklungsaufwände erheblich reduziert werden. Es basiert auf einem leichtgewichtigen JSON-RPC 2.0 Protokoll, welches auf die Interaktion mit Foundation-Models optimiert ist.
Während herkömmliche Ansätze bei der Integration und Verarbeitung von Daten in KI-Systemen oft aufwendig und fehleranfällig sind, setzt MCP auf Effizienz und Standardisierung. Dadurch adressiert es grundlegende Herausforderungen, die in der Entwicklung moderner Systeme häufig auftreten, und erleichtert die Arbeit von Entwicklern erheblich. Zu den zentralen Problemfeldern, die MCP löst, gehören:
- Reduktion von Entwicklungsaufwand: Vor der Einführung von MCP mussten für jede Datenquelle individuelle Schnittstellen entwickelt werden. MCP ermöglicht stattdessen die Wiederverwendbarkeit bestehender Server und reduziert so Entwicklungszeit und -kosten.
- Vereinheitlichung des Zugriffs: Als standardisiertes, JSON-RPC 2.0-basiertes Protokoll erlaubt MCP den Zugriff auf vielfältige Datenquellen, darunter lokale Dateien, Datenbanken oder REST-APIs, über ein einheitliches Interface.
- Direkte Integration mit LLMs: MCP wurde speziell darauf ausgelegt, KI-Modelle (wie LLMs) effizient mit kontextrelevanten Informationen zu versorgen. Es nutzt die Fähigkeit der LLMs, Daten dynamisch zu interpretieren, anstatt diese vorab mühsam zu modellieren.
- Skalierbarkeit und Flexibilität: Systeme, die auf MCP basieren, sind nicht nur leichter skalierbar, sondern unterstützen durch Wiederverwendung vorhandener Infrastruktur auch eine kosteneffiziente Implementierung.
Um diesen Herausforderungen effektiv zu begegnen, bietet MCP eine klar strukturierte Architektur. Die Schlüsselfunktionen von MCP wurden darauf ausgelegt, die beschriebenen Probleme nicht nur zu lösen, sondern auch eine flexible Grundlage für die Integration und Erweiterung von Systemen zu schaffen. Im Folgenden werden diese zentralen Konzepte detaillierter vorgestellt:
- Prompts: Aufgabenstellungen oder Anfragen, die an den MCP-Server gesendet werden und den Kontext sowie die Zielsetzung definieren. Beispiel: “Beschreibe Gerät XY.”
- Resources: Daten oder Inhalte, die über den MCP-Server bereitgestellt werden, statisch (z. B. gespeicherte Texte) oder dynamisch (z. B. durch URI-Templates). Beispiel: “Typenschild von Gerät XY.”
- Tools: Erlauben, spezifische Funktionen auszuführen, z. B. Datenverarbeitung oder API-Operationen. Beispiel: “Führe Diagnosefunktion Z auf Gerät XY aus.”
- Sampling: Dient zur Optimierung von Antworten, indem mehrere Varianten generiert und priorisiert werden – hilfreich bei generativen LLM-Anwendungen. Beispiel: “Zeige die 5 relevantesten Datenpunkte zu Gerät XY.”
- Roots: Definieren der Logik zur Weiterleitung von Anfragen an spezifische Ressourcen, Server oder Tools. Beispiel: “Rufe das Handbuch zu Gerät XY ab.”
- Transports: Regelt die Kommunikation zwischen Client und MCP-Server, standardisiert die Datentransfers, (z. B. JSON-RPC) und unterstützt Echtzeitübertragungen durch Mechanismen wie Server-Sent Events.
In Kombination bilden diese Funktionen ein intelligentes, skalierbares Framework für die effiziente Verarbeitung von Daten und die Implementierung KI-getriebener Anwendungsfälle. MCP optimiert insbesondere alltägliche Aufgaben wie den Zugriff auf disparate Datenquellen oder die Steuerung mehrerer Systeme über einheitliche Prompts – was es zu einem unverzichtbaren Werkzeug für modern ausgerichtete, KI-basierte Systeme macht.
Um die Funktionsweise sowie den Aufbau eines typischen MCP-Systems besser zu veranschaulichen, wird im Folgenden ein konkretes Beispiel betrachtet. Dieses Systembeispiel zeigt exemplarisch, wie die verschiedenen Komponenten von MCP miteinander interagieren, um eine effiziente Verarbeitung und Bereitstellung von Kontextinformationen sicherzustellen.
Beschreibung Systembeispiel MCP
| Element | Beschreibung |
|---|---|
| MCP Host | Der MCP Host (z.B. ein Foundation Model) sendet eine Kontextanfrage |
| Client | Der Client leitet sie weiter an den MCP Server |
| MCP Server | Der Server verarbeitet sie, z.B. durch Zugriff auf JSON, SQL, oder REST-APIs |
MCP bietet zwar eine sehr einfache Möglichkeit, Kontextinformationen einem Foundation-Model zur Verfügung zu stellen, jedoch ist MCP kein normierter Standard. Daher ist eine langfristige Stabilität der Funktionen und Schnittstellen aktuell schwer abzusehen. Die Welt rund um Foundation-Models dreht sich schnell, so wird sich das MCP auch weiterentwickeln.
Vergleich der Konzepte
Um die Unterschiede, Stärken und Einsatzbereiche von AAS und MCP deutlicher hervorzuheben, bietet die folgende Tabelle eine Gegenüberstellung der beiden Ansätze. Sie zeigt anschaulich, wie sich diese Protokolle in ihrer Architektur, Zielsetzung und ihrem Einsatzgebiet ergänzen oder unterscheiden.
| Merkmal | AAS (Asset Administration Shell) | MCP (Model Context Protocol) |
|---|---|---|
| API-Art | REST-API, AASX-Dateiformat | JSON-RPC 2.0 |
| Standards & Normen | IEC-Normen (IEC 63278) & standardisierte Metamodelle |
Keine festen Standards, leichtgewichtig und flexibel |
| Semantik | Semantische Modellierung durch Submodel-Struktur unterstützt durch Normen wie ECLASS | Datenkontext wird dynamisch während der Nutzung interpretiert |
| Stabilität bei Änderungen | Hohe Stabilität durch standardisierte Struktur und Semantik, wenig anfällig für spontane Änderungen | Änderungsempfindlich, da keine Normierung erfolgt; stark abhängig von dynamischen Daten |
| Komplexität | Höher, erfordert initialen Modellierungsaufwand | Niedrig, schnelle Implementierung möglich |
| Zugänglichkeit für Entwickler:innen | Komplex und mit steiler Lernkurve verbunden | Einfach und sofort benutzbar, ideal für KI-basierte Anwendungen |
| Interoperabilität | Hoch, standardisierte Semantik ermöglicht langfristige Konnektivität und Konsistenz zwischen Systemen | Flexibilität ermöglicht Anbindung an viele Datenquellen, aber geringere Standardisierung kann Fehler erzeugen |
| Einsatzgebiet | Langfristige industrielle Anwendungen mit starken Compliance- und Normanforderungen | Flexibler und schneller Einsatz für dynamische, KI- und datengetriebene Anwendungen |
| Langzeitsicherheit | Sehr hoch durch normierte und strukturierte Datenbasis | Mittlere bis geringe Sicherheit, abhängig von Datenquelle und Konsistenz der verwendeten Kontexte |
| Unterstützung durch KI | Indirekt, durch Bereitstellung von semantisch hochwertigen Submodellen | Direkte Integration, für KI-Anwendungen optimiert (z. B. LLM-Konnektivität) |
| Erlangte Domäneninteroperabilität | Durch vorhergehende, spezifische semantische Modellierung | Dynamisch während der Laufzeit erreicht, durch KI und kontextbasierte Übersetzungen |
| Wartungsaufwand | Höher, da Standardkonformität und Semantik über die Lebenszeit erhalten bleiben müssen | Niedriger, flexible Anpassungen ohne vorstrukturierte Modelle möglich |
| Beispiele für Stärken | Digitaler Zwilling, Digital Product Pass, interoperable Langzeitprojekte | Chatbots, Automatisierung mit KI, dynamische Datenintegration |
Die Tabelle verdeutlicht, dass sowohl AAS als auch MCP spezifische Stärken und Einsatzgebiete haben. Während AAS durch tiefe Semantik und Normkonformität vor allem in langfristigen und stabilitätsorientierten Anwendungen punktet, bietet MCP durch seine Flexibilität und Effizienz klare Vorteile für KI- und datengetriebene Szenarien. Im nächsten Abschnitt wird näher beleuchtet, wie diese beiden Ansätze – einzeln oder in Kombination – in der Praxis eingesetzt werden können und welche Potenziale sich dabei durch die Integration von LLMs ergeben.
Konkurrenz oder Koexistenz?
Kann MCP mit seiner einfachen, flexiblen Architektur und schnellen Entwicklungszyklen die AAS verdrängen? Aus der Praxis zeigt sich Folgendes:
- Entwickler:innen schätzen einfache und sofort nutzbare Schnittstellen.
- MCP eignet sich ideal für viele Anwendungen wie Chatbots, Assistenten oder Automatisierung.
- AAS bietet eine tiefgreifende semantische Basis, erfordert jedoch anfänglich höheren Aufwand für Modellierung und Integration.
- Die AAS-Konzepte sind oft komplex und von offenen sowie widersprüchlichen Themen der Industrie geprägt, was ihre Nutzung für Nicht-Experten erschwert.
Durch die Integration leistungsstarker LLMs wächst der Konkurrenzdruck weiter: LLMs können unterschiedliche semantische Kontexte erkennen und automatisch aufeinander abbilden – Fähigkeiten, die vorher explizit modelliert werden mussten. Ein Beispiel hierfür wäre das Verständnis, dass Begriffe wie “Temperatursensor 1” und “ZoneHeatLevel” denselben Wert bezeichnen.
MCP in Kombination mit LLMs kann damit die Komplexität der AAS teilweise ersetzen und bestimmte Anwendungsfälle schneller und mit weniger Aufwand umsetzen. Es entsteht sogar das Potenzial, einige semantische Vorgaben der AAS dynamisch durch das kontextuelle Sprachverständnis von LLMs zu lösen. Allerdings bleibt fraglich, ob diese Flexibilität langfristig dieselbe Stabilität und Interoperabilität erreichen kann wie die strukturierte AAS-Architektur.
Die Stärke von LLMs liegt in der Bewältigung nichtdeterministischer Aufgaben. Diese Stärke kann jedoch zum Nachteil werden, da ein Foundation-Model stark von der Qualität und Konsistenz der zugrundeliegenden Daten abhängt. Fehlende oder inkonsistente Kontexte können zu falschen Interpretationen führen. Werden LLMs jedoch auf klar strukturierte Submodelle der AAS angewendet, fällt es ihnen wesentlich leichter, Domänenkonzepte präzise zu verstehen und korrekt zu übertragen.
Um die unterschiedlichen Ansätze von MCP und AAS sowie deren Interaktion mit LLMs besser zu veranschaulichen, werden im Folgenden zwei Architekturmodelle vorgestellt. Diese zeigen, wie LLMs die semantische Vermittlung zwischen Datenquellen übernehmen können – mit und ohne eine vorgelagerte Harmonisierung durch die AAS.
In diesem Szenario greift das LLM direkt über MCP auf Datenquellen aus unterschiedlichen fachlichen Domänen zu. Es interpretiert diese kontextuell und erzeugt daraus einen gemeinsamen Zielkontext – etwa für ein spezifisches Zielsystem oder eine Anwendung, die auf standardisierte Informationen angewiesen ist. Das LLM wird damit selbst zur Instanz, die semantische Vermittlung leistet.
Die Qualität dieser Ziel-Kontextualisierung hängt jedoch maßgeblich von der Qualität der Datenquellen ab. Weil LLMs nicht deterministisch arbeiten, kann diese Interpretation sowohl zu hochgradig brauchbaren Ergebnissen führen – als auch zu unerwarteten, ungewollten Bedeutungsverschiebungen. Insbesondere dann, wenn die zugrundeliegenden Quellen inkonsistent, widersprüchlich oder kontextarm modelliert sind.
In diesem erweiterten Beispiel erfolgt eine vorgelagerte Neutralisierung durch Submodelle innerhalb der AAS. Das LLM greift über MCP auf diese semantisch harmonisierte Zwischenschicht zu, interpretiert sie kontextabhängig und erzeugt daraus einen konsolidierten Ziel-Domain-Kontext. Dieser kann etwa spezifisch auf ein Zielsystem oder eine nachgelagerte Anwendung zugeschnitten sein.
Diese zweite Variante erhöht die Konsistenz und reduziert Fehlinterpretationen, da das LLM auf eine einheitlich strukturierte, domänenunabhängige Datenbasis zurückgreifen kann. Die semantische Komplexität der Quell-Domänen wird dadurch vorverarbeitet, was den Interpretationsaufwand für das LLM minimiert.
Die Frage nach Konkurrenz oder Koexistenz zeigt, dass MCP und AAS jeweils spezifische Stärken und Herausforderungen mitbringen. Doch wie können diese beiden Ansätze in der Praxis kombiniert werden, um das Beste aus beiden Welten zu vereinen? Der folgende Abschnitt beleuchtet mögliche Lösungsansätze und zeigt, wie eine Integration von MCP, AAS und LLMs zu einem leistungsstarken Gesamtsystem führen kann.
Lösung und Ergebnis: Gemeinsam stark durch Integration
Während AAS strukturierte, normative und interoperable Daten liefert, bietet MCP dynamischen, KI-fähigen Zugriff auf kontextrelevante Informationen. Besonders in Kombination mit LLMs können beide Konzepte ihre Stärken entfalten: AAS stellt qualitativ hochwertige, domänenspezifisch modellierte Informationen bereit, MCP und LLMs ermöglichen deren flexiblen, semantisch intelligenten Zugriff und Interpretation.
Ein integriertes System kann z.B. über einen Adapter MCP-Anfragen direkt auf AAS-Submodelle mappen. Dadurch entstehen hybride Architekturen, die:
- nachhaltige Semantik und Stabilität (durch AAS)
- hohe Flexibilität, Geschwindigkeit und Interoperabilität (durch MCP)
- automatisierte Kontextübersetzung und Domain-Abgleich (durch LLMs)
bieten.
Ergebnis: Die scheinbare Konkurrenz wird zur Kooperation – die Kombination aus AAS, MCP und LLM führt zu einem System, das sowohl technologische Robustheit als auch agile Weiterentwicklung unterstützt.
Nach der Darstellung eines integrierten Ansatzes, der die Stärken von AAS, MCP und LLMs kombiniert, stellt sich die Frage, wie dieses Konzept in realen Szenarien angewendet werden kann. Ein konkretes Beispiel hierfür ist der digitale Product Pass, der eindrucksvoll aufzeigt, wie hybride Architekturen praktische Herausforderungen effizient lösen können.
Konkretes Beispiel: Digitaler Product Pass
Eines der dringendsten Themen, die im Bereich des digitalen Zwillings anstehen, ist der digitale Product Pass (DPP). Dieser soll alle Informationen über ein Produkt liefern, und das über sehr lange Zeit. Dort sollen unter anderem Materialzusammensetzungen und andere wichtige Aspekte, die für das Recycling wichtig sind, abgespeichert werden. Auch Prüfungen wie TüV oder anderweitige Zertifizierungen sollen in den Product Pass integriert werden.
Eine der größten Herausforderungen ist, dass diese Informationen zum Teil sensibel sind. Materialzusammensetzungen können unter anderem ein Betriebsgeheimnis sein. Wie können nun Fragestellungen rund um die Materialzusammensetzung beantwortet werden, ohne Geheimnisse zu verraten? Die Lösung ist ein sogenanntes Zero-Knowledge-Proof. Dabei handelt es sich um ein kryptografisch gesichertes Verfahren, mit dem Wissen gesichert übertragen wird, ohne konkrete Informationen preiszugeben.
Bei der Materialzusammensetzung wäre so eine Frage zum Beispiel: “Sind Schadstoffe enthalten?”. Diese Frage wird an ein System gesendet, welches mit einer signierten Antwort mit einem Ja oder Nein antwortet. Um zu beweisen, dass diese Antwort echt ist, ist zusätzlich eine Signatur einer Faktenabfrage enthalten, die beweist, dass für die Generierung der Antwort tatsächlich vertrauenswürdige Fakten benutzt wurden.
Diese Art von Frage-Antwort-Verhalten passt exakt zu den Konzepten des MCP, um nach Fakten oder Ressourcen zu fragen. Die AAS-API und der MCP-Server können für diese Anforderungen perfekt zusammen arbeiten. Die AAS-API mit ihren Submodellen stellt die Fakten bereit. Eine Abfrage des Submodels oder eines Submodel-Elements wird mit einem Proof signiert, dass diese Fakten tatsächlich von dem MCP-Server abgerufen wurden. Der MCP-Server nutzt diese Fakten, um einen Prompt zu beantworten, und gibt sein Proof zusammen mit dem Proof der AAS-API zurück an den Client. Dieser kann dann beide Proofs überprüfen und somit die Echtheit und Wahrheit der Abfrage bestätigen.
Das folgende Diagramm zeigt anhand des Beispiels des Recyclings eines Laptops, wie ein solches System funktionieren kann. Dieser besitzt eine digitale Identität gemäß dem Standard IEC-61406, welcher vorschreibt, dass diese Identität einer URL gleicht, welche aufgelöst werden kann, um an die Informationen des digitalen Produkt-Passes zu kommen.
| Beschreibung | |
|---|---|
| 1 | Ein unbekannter Laptop mit einer digitalen Identität soll recycelt werden. |
| 2 | Der “Recycling Expert” fragt sein “Recycling Information System” nach einer Anleitung, wie das Gerät recycelt werden kann. |
| 3 | Das “Recycling Information System” besitzt den Zugriff auf ein Foundation-Model, welches mithilfe eines MCP-Clients auf zusätzliche Kontexte zugreifen kann, um konkrete Anweisungen für das Recycling zu generieren. Der MCP Client sucht anhand der digitalen Identität den passenden MCP-Server, um nach für das Recycling relevantem Wissen zu fragen. Der MCP Client findet dafür ein Proof “chemicalSensitiveInsights”, mit dem verschiedene Schadstoffe abgefragt werden können. Als Parameter kann ein bestimmtes Material mittels dessen CAS-Nummer angegeben werden. Die Anfrage würde so aussehen für Blei (CAS-Nr 7439–92–1): { |
| 4 | Der MCP Server des Herstellers nutzt diese Wissensabfrage, um bei seinem eigenen AAS-System die Bestandteile (BillOfMaterial) des Laptops abzufragen. Der MCP Server bekommt in der Antwort der Abfragen an der AAS-API jeweils ein Credential zurück, das beweist, dass diese Daten abgefragt wurden. Dieses Credential kann in der Form eines JWT an den MCP Server zurückgegeben werden: # Header |
| 5 | Der MCP Server geht nun die einzelnen Bestandteile durch und erfragt Fakten, um nach bleihaltigen Bestandteilen zu suchen. Für die Batterien und Microcontroller muss er deshalb fremde AAS-APIs abfragen. Von diesen bekommt er ebenfalls ein Credential, welches die Abfrage bestätigt. |
| 6 | Mit den erhaltenen Informationen erzeugt der MCP Server eine Antwort mit der Liste an bleihaltigen Bestandteilen. In der Antwort ist ebenso die Liste der Credentials der erfolgten AAS-API-Abfragen. Außerdem fügt der MCP Server ein eigenes Credential hinzu, das die Antwort selbst signiert. { Das JWT des Credentials könnte so aufgebaut sein: # Header Der MCP Client kann nun das Credential des MCP Servers und die der AAS-API-Abfragen prüfen. Da die fremden JWT Credentials Teil des JWT des MPC Client sind, ist die gesamte Transaktion prüfbar und vertrauenswürdig. |
| 7 | Das Foundation-Model des Recycling-Information-Systems nimmt die Informationen des MCP Clients und erstellt daraus eine Anleitung mit Hinweisen auf Schadstoffe. Das System selbst protokolliert die Abfrage des MCP Clients und kann somit nachweisen, dass es die Informationen für das Recycling erhalten hat, welche vertrauenswürdig sind. |
Das beschriebene Beispiel zeigt sehr deutlich, wie die AAS und das MCP effizient zusammenarbeiten können und sich gegenseitig ergänzen. Wird beides mit bestehenden Sicherheitsmechanismen kombiniert, entsteht eine tragfähige moderne Lösung, die einen sicheren Wissensaustausch ermöglicht, ohne konkrete Geheimnisse offenzulegen. Das gleiche Konzept ließe sich nicht nur auf das Thema Recycling anwenden, sondern auch auf andere Bereiche der Industrie. Zum Beispiel, wenn es darum geht, jemandem Dritten Zugriff auf geschütztes Wissen zu gewähren. So könnte eine Zertifizierungsstelle, wie der TÜV, Zugriff auf sensible Informationen erhalten, ohne diese direkt einzusehen, zum Beispiel um eine Checkliste abzuarbeiten. Gerade der Zugriff auf Materialzusammensetzungen oder konkrete Eigenschaften sind strategisch sensible Bereiche, die Einblicke in genaue Rezepturen oder Baupläne nicht erlauben. Problemlos ist jedoch die Abfrage, ob bestimmte Materialien oder Eigenschaften vorhanden sind.
Eine Lösung ohne MCP nur mit der aktuellen AAS API wäre so nicht möglich, da diese darauf ausgelegt ist Informationen bereitzustellen. So würde eine AAS-API ein Datenblatt herausgeben, das die Informationen enthalten könnte. Jedoch wären auf dem Datenblatt mehr Informationen als nötig abgebildet. Zudem müsste das Datenblatt erst einmal ausgewertet werden, um das nötige Wissen zu erhalten. In diesem Beispiel müsste das System des Recyclingbetriebs sich mit der Zusammensetzung von Legierungen auskennen, um herauszufinden, ob diese Blei enthalten.
Bei einer Lösung ohne AAS-API wäre zwar der Wissensaustausch möglich, jedoch hätte es der MCP Server schwerer, die verschiedenen Quellen abzufragen, da jeder Hersteller seine eigene API bereitstellen würde, welche integriert werden müsste. Zudem würden sich so in dem MCP Server die Domains der Hersteller wiederspiegeln. Durch die Vereinheitlichung der Daten in Submodele bekommt der MCP Server von allen Herstellern die gleiche Antwort und kann diese besser zusammenführen.
Durch eine vermehrte Kombination aus AAS und MCP könnte langfristig eine standardisierte Variante des MCP in den AAS-Standard einziehen, so könnte die bestehende REST-API um eine MCP-RPC-API ergänzt werden. Somit könnte jedes System, das eine AAS-API anbietet, auch MCP Anfragen beantworten. Spätestens mit der Verpflichtung zur Bereitstellung von Informationen für Batterie-Systeme mit dem Battery-Passport bis zum 1.Januar 2026 wird eine standardisierte Lösung zur vertrauensvollen Abfrage von Wissen Pflicht für viele Unternehmen, die Produkte mit Batterien produzieren.