Ein KI-Modelle und AI Agents halten Einzug in die industrielle Automatisierung. Sie sollen Produktionsdaten analysieren, Anomalien erkennen und perspektivisch auch Steuerungseingriffe vornehmen. Doch zwischen einem Large Language Model (LLM) und einer laufenden Fertigungslinie liegt ein grundlegendes Architekturproblem: Wie erhält ein KI-System strukturierten, sicheren und kontextualisierten Zugang zu Echtzeit-Daten aus dem Unified Namespace (UNS)? Bislang bauen Unternehmen dafür individuelle Integrationen – direkte UNS-Subscriptions, Custom REST-Wrapper oder proprietäre Konnektoren. Das Ergebnis: eine wachsende Zahl schlecht wartbarer Punkt-zu-Punkt-Verbindungen. Das Model Context Protocol (MCP) bietet einen standardisierten Ausweg. Dieser Artikel erklärt, wie das MCP im Unified Namespace (UNS) als zentrale Architekturschicht für die KI-Integration fungiert und welche Designentscheidungen IT/OT-Architekten dabei treffen müssen.
Was ist Model Context Protocol (MCP)?
Das Model Context Protocol (MCP) ist ein offener Standard, der definiert, wie KI-Modelle mit externen Datenquellen und Werkzeugen kommunizieren. Anthropic hat MCP 2024 veröffentlicht; seitdem wird es von einer wachsenden Community weiterentwickelt. Die zentrale Idee: Statt jede Datenquelle individuell an ein KI-Modell anzubinden, stellt MCP eine einheitliche Schnittstelle bereit – vergleichbar mit USB-C als universeller Anschluss für Peripheriegeräte.
Die drei Bausteine von MCP
MCP strukturiert die Kommunikation über drei Konzepte:
- Tools: Ausführbare Funktionen, die das KI-Modell aufrufen kann. Ein Tool könnte
get_machine_statusheißen und den aktuellen Zustand einer Maschine aus dem UNS abfragen. Tools ermöglichen sowohl lesende als auch schreibende Operationen. - Resources: Datenquellen, die dem KI-Modell als Kontext bereitgestellt werden. Im UNS-Kontext könnte eine Resource die Topic-Hierarchie eines Standorts abbilden – inklusive Metadaten zu Einheiten, Datentypen und Aktualisierungsfrequenzen.
- Prompts: Vordefinierte Abfragemuster, die wiederkehrende Anfragen standardisieren. Beispiel: ein Prompt-Template für Schichtberichte, das automatisch die relevanten KPIs aus dem UNS zusammenstellt.
Abgrenzung zu klassischen APIs
MCP ist kein Ersatz für REST oder GraphQL. Es operiert auf einer anderen Ebene: Während eine REST API einen festen Satz von Endpunkten bereitstellt, beschreibt MCP dynamisch, welche Fähigkeiten ein Server bietet. Das KI-Modell kann diese Fähigkeiten zur Laufzeit entdecken und nutzen – ohne dass die Integration bei jeder Änderung der Datenstruktur angepasst werden muss.
Warum MCP im Unified Namespace (UNS)?
Der Unified Namespace (UNS) löst das Problem der Datenverfügbarkeit: Alle relevanten Informationen aus OT- und IT-Systemen fließen als Single Source of Truth (SSOT) in eine zentrale, Broker-basierte Datenarchitektur. Für klassische Konsumenten – Dashboards, MES, ERP-Systeme – funktioniert dieses Modell. Doch KI-Systeme haben andere Anforderungen.
Drei Herausforderungen für KI im UNS
- Kontextualisierung: Ein UNS-Topic wie site01/area02/line03/machine04/temperature liefert einen Zahlenwert. Ein KI-Modell braucht aber Kontext: Welche Einheit? Welcher Normalbereich? Welche Maschine genau? Diese Metadaten sind im UNS oft vorhanden, aber über verschiedene Topics verteilt. Ein KI-Modell muss wissen, wo es suchen soll.
- Zugriffskontrolle: Nicht jeder AI Agent sollte Schreibzugriff auf Sollwerte haben. MQTT bietet ACLs auf Topic-Ebene, aber die Granularität für KI-Anwendungsfälle reicht oft nicht aus. Ein Agent soll vielleicht Temperaturwerte lesen, aber keine Rezeptparameter ändern dürfen – auch wenn beide im selben Topic-Bereich liegen.
- Aktionsfähigkeit: Ein AI Agent, der nur liest, ist begrenzt nützlich. Sobald er Aktionen auslösen soll – Benachrichtigungen senden, Sollwerte anpassen, Wartungstickets erstellen – braucht er klar definierte, validierte Schnittstellen. Direkte UNS-Publishes ohne Validierungsschicht sind ein Sicherheitsrisiko.
Ohne Standard: Spaghetti-Architektur
Ohne ein standardisiertes Protokoll baut jeder AI Agent seine eigene Integrationslogik. Agent A nutzt einen Python-MQTT-Client mit eigener Topic-Interpretation. Ein Agent B greift über eine REST API auf einen UNS-Gateway zu. Agent C liest direkt aus der Datenbank. Das Ergebnis ist eine Punkt-zu-Punkt-Architektur, die mit jedem neuen Agenten komplexer wird – genau das Muster, das der UNS auf der Datenebene bereits gelöst hat.
MCP überträgt das UNS-Prinzip auf die KI-Schicht: ein standardisierter, zentraler Zugang statt individueller Verbindungen.
Referenzarchitektur: MCP-Server im UNS
Die folgende Architektur zeigt, wie ein MCP-Server als Vermittlungsschicht zwischen AI Agents und dem UNS funktioniert.
Architekturübersicht
Komponenten im Detail
MCP-Server (UNS-Gateway): Der MCP-Server ist die zentrale Komponente. Er verbindet sich mit dem UNS Broker, versteht die Topic-Hierarchie des UNS und exponiert die Daten in Form von MCP-Tools und -Resources. Er übersetzt die Frage eines AI Agents in die richtige Kombination aus UNS-Subscriptions und -Publishes.
MCP Client: Der MCP Client läuft als Bestandteil des KI-Systems – typischerweise im LLM-Host oder Agent-Framework. Er entdeckt automatisch die verfügbaren Tools und Resources des MCP-Servers und stellt sie dem KI-Modell zur Verfügung.
Tools: Funktionen für den AI Agent
Der MCP-Server definiert Tools als kontrollierte Zugangspunkte zum UNS:
| Tool | Beschreibung | Zugriff |
|---|---|---|
get_machine_status |
Aktueller Zustand einer Maschine | Read |
query_production_kpi |
Produktionskennzahlen über Zeitraum | Read |
list_active_alarms |
Offene Alarme eines Standorts | Read |
set_target_value |
Sollwert einer Regelgröße setzen | Write |
create_maintenance_ticket |
Wartungsauftrag anlegen | Write |
Jedes Tool hat ein definiertes Schema für Ein- und Ausgabeparameter. Der MCP-Server validiert die Parameter, bevor er den entsprechenden UNS-Publish ausführt. Damit entsteht eine kontrollierte Schnittstelle – der AI Agent kann keinen beliebigen Payload in den UNS senden.
Resources: Kontext für das KI-Modell
Resources liefern dem KI-Modell den nötigen Kontext:
- Topic-Hierarchie: Die vollständige Struktur des UNS eines Standorts, inklusive ISA-95-Ebenen (enterprise / site / area / line / cell)
- Daten-Dictionary: Beschreibung der verfügbaren Signale mit Einheiten, Wertebereichen und Aktualisierungsfrequenzen
- Betriebskontext: Schichtpläne, Rezepte, Produktionsaufträge – Informationen, die ein KI-Modell braucht, um Messwerte korrekt zu interpretieren
Einordnung in die ISA-95-Ebenen
Der MCP-Server operiert auf der Integrationsschicht zwischen Level 3 (MES/MOM) und Level 4 (ERP/Business). Er konsumiert Daten aus allen Ebenen des UNS, exponiert sie aber nur gefiltert und kontextualisiert an die KI-Schicht. Damit folgt er dem UNS-Prinzip: jede Schicht nutzt die Daten, die sie braucht, ohne direkte Abhängigkeiten zu den darunterliegenden Systemen.
MCP vs. direkte UNS-Anbindung
Nicht jeder Anwendungsfall erfordert MCP. Die folgende Tabelle hilft bei der Entscheidung.
| Kriterium | Direkte UNS-Anbindung | MCP-Server |
|---|---|---|
| Standardisierung | Proprietär pro Agent | Offener Standard |
| Kontextualisierung | Manuell, pro Agent | Zentral im MCP-Server |
| Zugriffskontrolle | MQTT ACLs (Topic-Ebene) | Tool-Ebene + Validierung |
| Schreibende Zugriffe | Unkontrolliert | Validiert über Tool-Schema |
| Modell-Austauschbarkeit | Agent neu implementieren | MCP-Interface bleibt stabil |
| Initiale Komplexität | Gering | Mittel |
| Skalierung bei >3 Agents | Exponentiell steigend | Linear |
Wann reicht eine direkte Anbindung?
Für einfache, lesende Anwendungsfälle mit einem einzelnen Agent – etwa ein Dashboard-Bot, der Produktionszahlen zusammenfasst – kann eine direkte UNS-Subscription ausreichen. Der Agent subscribt auf die relevanten Topics, parst die Payloads und verarbeitet sie.
Wann macht MCP den Unterschied?
MCP wird relevant, sobald:
- Mehrere AI Agents auf das UNS zugreifen (Wiederverwendung der Tool-Definitionen)
- Schreibende Zugriffe nötig sind (Validierung und Autorisierung)
- Modelle ausgetauscht werden sollen (Wechsel von GPT zu Claude zu Open-Source ohne Integrationsumbau)
- Compliance-Anforderungen bestehen (Auditierung aller KI-Zugriffe über eine zentrale Schicht)
Damit wird der MCP-Server zur entscheidenden Architekturschicht, sobald KI nicht mehr experimentell, sondern produktiv, skalierbar und governance-konform im Unified Namespace betrieben werden soll.
Aktuelle Limitationen von MCP
So vielversprechend MCP im Unified Namespace (UNS) ist, aus Sicht von IT/OT-Architekten und Enterprise-Security-Teams bestehen derzeit noch relevante Einschränkungen, u.a.:
1. Rollen- und Policy-Modell noch nicht standardisiert
Für MCP existiert bislang kein ausgereiftes, standardisiertes RBAC-/ABAC-Modell auf Protokollebene. Autorisierung erfolgt typischerweise implementierungsspezifisch im MCP-Server selbst. Für Enterprise-Umgebungen mit Zero-Trust-Architekturen, zentralem IAM und fein granularen Policies bedeutet das zusätzlichen Integrationsaufwand. Die Herausforderung für Unternehmen:
- Zusätzlicher Integrationsaufwand in Zero-Trust-Architekturen
- Schwierige Anbindung an zentrales Identity & Access Management (IAM)
- Fehlende Unterstützung für fein granulare Policies im Enterprise-Kontext
2. Unzureichende Auditierbarkeit und Nachvollziehbarkeit von KI-Entscheidungen
MCP ermöglicht zwar Logging auf Tool-Ebene, definiert aber keine standardisierte Struktur für revisionssichere Audit-Trails oder KI-Entscheidungsnachweise.
Kritisch für regulierte Industrien: In Branchen wie Pharma, Automotive oder Food & Beverage sind vollständige Traceability und Change-Historien verpflichtend. MCP bietet hier aktuell keine Out-of-the-Box-Lösung für Compliance-konforme Dokumentation.
3. Credential Management & Secrets Exposure
MCP Server benötigen privilegierte Zugangsdaten – API-Keys, Datenbank-Credentials, OAuth-Tokens – für die Integration mit Backend-Systemen. Aktuell fehlt jedoch eine standardisierte Secrets-Management-Strategie. Konkrete Sicherheitsrisiken:
- Credentials werden oft unsicher in Config-Files oder Environment Variables gespeichert
- Risiko der Exposition in Logs, Error Messages oder durch Kompromittierung des MCP Servers
- Bei erfolgreichem Angriff: Lateral Movement in verbundene Systeme möglich
4. Reifegrad und Einordnung für IT/OT-Architekten
MCP ist ein junger Standard. Industrietaugliche Referenzimplementierungen, zertifizierte Komponenten oder langfristig supportete Enterprise-Distributionen befinden sich noch im Aufbau. Für produktionskritische OT-Umgebungen bedeutet das eine sorgfältige Risikoabwägung. MCP sollte aktuell als Governance- und Integrationsschicht für KI-Anwendungsfälle betrachtet werden – nicht als sicherheitszertifizierte OT-Komponente. Wer MCP im produktiven Umfeld einsetzt, muss Security-by-Design, Netzwerksegmentierung, Human-in-the-Loop-Mechanismen und zentrale Identity-Integration konsequent ergänzen.
Best Practices für den erfolgreichen Einsatz
Die folgenden Best Practices zeigen, wie ein MCP-Server im Unified Namespace sicher und skalierbar implementiert wird.
1. Human in the Loop: Kontrollierte Schreiboperationen
Write-Tools sollten – insbesondere bei produktionskritischen Prozessen – nicht autonom durch einen AI-Agent ausgeführt werden. Statt direkter Write-Ausführung:
- Agent erzeugt eine Handlungsempfehlung
- MCP-Server markiert die Operation als „pending approval“
- Menschliche Freigabe (z. B. Schichtleiter) erfolgt über UI oder Workflow-System
- Erst danach wird der Write-Call an den UNS ausgeführt
HITL-Empfehlungen:
| Szenario | HITL-Empfehlung | Bewertung |
|---|---|---|
| Reines Monitoring | Nicht erforderlich | AI liest nur Daten |
| KPI-Analyse | Nicht erforderlich | Keine Prozessveränderung |
| Optimierungsvorschläge (ohne Ausführung) | Empfohlen | Entscheidung bleibt beim Menschen |
| Produktionsrelevante Parameteränderungen | Zwingend erforderlich | Einfluss auf Qualität, OEE, Ausschuss |
| Sicherheitskritische Prozesse | Zwingend erforderlich | Personen- oder Anlagensicherheit betroffen |
| Rezeptur- oder Chargenänderungen | Zwingend erforderlich | Compliance- und Rückverfolgbarkeitsrelevant |
2. Sicherheit: Defense in Depth
Behandle den MCP-Server als sicherheitskritische Komponente. Trenne Read-only-Tools klar von Write-Tools und vergib Berechtigungen pro Agent-Rolle. Ein Monitoring-Agent erhält nur Lesezugriff. Ein Optimierungsagent erhält gezielt Schreibzugriff auf definierte Sollwerte – nie auf die gesamte Topic-Hierarchie.
Zusätzlich: Implementiere Rate Limiting auf Tool-Ebene. Ein AI Agent, der in einer Schleife 1.000 get_target_value Aufrufe pro Sekunde absetzt, deutet auf ein Problem hin – nicht auf einen legitimen Anwendungsfall.
3. Granularität: Nicht zu fein, nicht zu grob
Vermeide ein 1:1-Mapping zwischen UNS-Topics und MCP-Tools. Ein Tool get_temperature_machine_04 ist zu spezifisch. Besser: get_machine_signal(machine_id, signal_name) mit Parametern. Gleichzeitig ist ein einzelnes Tool query_uns(topic) zu generisch – es umgeht die Validierungs- und Kontextualisierungsschicht.
Orientiere dich an fachlichen Operationen: Was würde ein Schichtleiter abfragen? Maschinenstatusbericht, Produktionskennzahlen, offene Alarme. Das sind sinnvolle Tool-Granularitäten.
4. Kontextualisierung: Metadaten immer mitliefern
Jede Tool-Antwort sollte neben dem Rohwert auch Einheit, Zeitstempel, Normalbereich und Signalquelle enthalten. Ein KI-Modell, das nur den Wert 87.3 erhält, kann damit wenig anfangen. Ein Response wie {"value": 87.3, "unit": "¬∞C", "range": [60, 95], "source": "site01/area02/line03/oven01/temperature", "timestamp": "2025-01-15T14:23:00Z"} liefert den nötigen Kontext für eine fundierte Analyse.
5. Governance: MCP-Server als kontrollierter Gateway
AI Agents sollten nie direkt mit dem UNS Broker kommunizieren. Der MCP-Server ist der einzige Zugangspunkt. Das ermöglicht:
- Zentrales Logging aller KI-Zugriffe
- Einheitliche Autorisierung
- Konsistente Datenaufbereitung
- Einfacheres Debugging bei Fehlverhalten eines Agents
6. Monitoring und Audit
Logge jeden MCP-Tool-Aufruf mit Agent-ID, Zeitstempel, Tool-Name, Parametern und Ergebnis. Diese Logs dienen drei Zwecken: Debugging bei Fehlverhalten, Compliance-Nachweis und Optimierung der Tool-Definitionen. Wenn ein bestimmtes Tool nie aufgerufen wird, ist es überflüssig. Wenn ein Agent immer die gleiche Abfolge von Tools nutzt, könnte ein zusammengesetztes Tool effizienter sein.
Fazit
MCP schließt eine architektonische Lücke im Unified Namespace: die standardisierte Anbindung von KI-Systemen. Statt jede KI-Anwendung individuell mit dem UNS Broker zu verdrahten, stellt ein MCP-Server eine kontrollierte, validierte und kontextualisierte Schnittstelle bereit. Für IT/OT-Architekten bedeutet das drei konkrete Handlungsempfehlungen:
- MCP-Server als Standardkomponente einplanen. Wer AI Agents im UNS einsetzt, sollte von Beginn an eine MCP-Schicht vorsehen – nachträgliche Integration ist aufwändiger.
- Tool-Design fachlich denken. Die MCP-Tools orientieren sich an Betriebs-Operationen, nicht an UNS-Topic-Strukturen.
- Governance nicht nachlagern. Zugriffskontrolle, Logging und Monitoring gehören in die erste Iteration, nicht ins Backlog.
Das MCP-Ökosystem wächst stetig. Industrielle MCP-Server, die spezifisch auf UNS-Architekturen zugeschnitten sind, werden der nächste logische Schritt sein. Wer heute die Architekturgrundlage legt, ist für diesen Schritt vorbereitet.
