BLUF: Industrielle KI scheitert meist vor der Modellauswahl. Es fehlt ein Datenvertrag: Ein Temperaturwert kommt ohne stabile Asset-Identität, Einheit, technischen Wertebereich, Quellzeitstempel, Qualitätszustand, Maschinenzustand, Verantwortlichkeit oder zulässige Nutzung. Ein LLM, Anomaliemodell oder Regelwerk kann trotzdem eine plausible Antwort erzeugen. Es kann jedoch nicht belegen, dass diese Antwort das richtige Asset betrifft, zwischen Linien vergleichbar ist oder sicher verwendet werden darf. Bauen Sie deshalb am Edge eine versionierte semantische Schnittstelle auf, validieren Sie sie vor der Inferenz und stellen Sie ihre kontrollierte Repräsentation über die Asset Administration Shell (AAS) bereit.
OPC UA ist eine tragfähige Grundlage für Quellmodelle, aber kein fertiger Vertrag. Das Data-Access-Modell umfasst technische Einheiten und Qualitätscodes. Die Interoperabilitätsleitlinie der OPC Foundation beschreibt den entscheidenden Punkt: Wert, Qualität und Zeitstempel sind erst mit Asset-Kontext belastbar. Die IDTA-AAS-Spezifikationen definieren Struktur, Schnittstellen und Semantik standardisierter digitaler Zwillinge. Keiner der Standards entscheidet jedoch über Verantwortlichkeiten, Kompatibilitätsregeln oder Testnachweise.
Die Architektur: Vertrag vor Feature
Behandeln Sie den Weg von SPS oder Historian zu einem KI-Feature als vier getrennte Verantwortlichkeiten. Lassen Sie weder einen Embedding-Job noch ein Notebook zur faktischen Integrationsschicht werden.
OPC-UA-Knoten / Historian-Replikat → Edge-Vertragsadapter → Validierungstor + Quarantäne → versionierter Ereignisspeicher / Feature View → AAS-Submodell + KI-Consumer.
1. Quelladapter: Lesen Sie freigegebene OPC-UA-Knoten und bewahren Sie NodeId/Namespace, Server- und Quellzeitstempel, StatusCode, technische Einheit und Quellendpunkt. Benennen oder konvertieren Sie Werte nicht stillschweigend.
2. Edge-Vertrag: Ordnen Sie Quellfelder einer stabilen Asset-ID und einem semantischen Konzept zu. Ergänzen Sie Maschinenzustand, Zulässigkeitsregel, Verantwortliche und Vertragsversion. Konvertieren Sie Einheiten nur über explizite getestete Regeln; Quellwert und Quelleinheit bleiben erhalten.
3. Validierungstor: Verwerfen, quarantänisieren oder markieren Sie Datensätze, die Typ-, Einheiten-, Bereichs-, Zeitstempel-, Qualitäts-, Zustands- oder Identitätsregeln verletzen. Erzeugen Sie einen Grundcode; unbekannte Qualität darf nie zu Gut werden.
4. AAS-Repräsentation: Veröffentlichen Sie freigegebene semantische Referenzen und Vertragsprovenienz als Submodell oder verknüpfte Submodellelemente. AAS semanticId macht die Schnittstelle auffindbar, ersetzt aber keine Laufzeitvalidierung.
Der Mindestvertrag
| Feld | Beispiel | Warum es unverzichtbar ist |
|---|---|---|
| asset_id | werk-3/linie-2/pumpe-17 | Verhindert Kollisionen lokaler Tag-Namen und verknüpft Nachweise mit einem Asset. |
| semantic_id + Eigenschaft | IEC-61360-/ECLASS-Referenz + lagertemperatur | Beschreibt Bedeutung jenseits eines Historian-Labels. |
| Wert, Einheit, technischer Bereich | 82,4 °C; 0–120 °C | Verhindert °F/°C-Fehler und markiert unplausible Werte. |
| Quellzeit, Eingangszeit, Zeitbasis | UTC-Quellzeit; Edge-Eingang | Trennt verspätete, wiederholte und zeitversetzte Beobachtungen. |
| Qualität + Maschinenzustand | Bad/Uncertain; Wartung | Verhindert, dass ein Modell Kalibrierung als Prozessnachweis behandelt. |
| Verantwortung + zulässige Nutzung | Reliability Engineering; nur beratend | Macht Zuständigkeit und Nutzung explizit. |
| Vertragsversion + Lineage | 1.4.0; NodeId und Adapter-Release | Ermöglicht Kompatibilitätsprüfung, Replay und Incident-Rekonstruktion. |
Kompatibilität ist eine Release-Entscheidung
Klassifizieren Sie Änderungen vor dem Deployment. Ein Patch präzisiert eine Beschreibung oder ergänzt ein optionales Feld. Ein Minor-Release ergänzt ein optionales semantisches Feld mit sicherem Default-Verhalten. Ein Major-Release verändert Einheit, Identitätssemantik, Bereichsbedeutung, Zustandsvokabular, Kardinalität oder zulässige Nutzung. Dafür brauchen Sie einen parallelen Vertrag, explizite Consumer-Migration und Replay-Nachweise – keinen Best-Effort-Parser. Das ist dieselbe Disziplin wie bei strukturierten LLM-Ausgaben als versioniertem API-Vertrag: Syntaxvalidierung beweist keine operative Gültigkeit.
Edge-Tests und absichtlich getestete Fehlermodi
Führen Sie Vertragsprüfungen bei jedem Adapter-Release und gegen aufgezeichnete Produktionsproben am Edge aus. Unit-Tests prüfen Dimensionen und Umrechnungsgenauigkeit; Schema-Tests fordern Pflichtfelder; Semantik-Tests lehnen inkompatible Asset-Klassen ab; Zeit-Tests begrenzen Skew und erkennen Zeitumkehr; Zustands-Tests schließen Wartungs- oder Bypass-Modi aus dem Normaltraining aus; Replay-Tests belegen, dass ein neuer Consumer alte Events noch interpretiert.
Halten Sie einen Quarantänestrom vor. Ein verworfenes Event verdeckt einen Fehler; ein quarantänisiertes Event mit Vertragsversion, Quellendpunkt, Grundcode und Probenreferenz erzeugt eine bearbeitbare Liste für den Datenverantwortlichen. Definieren Sie Annahmeschwellen pro Use Case: Ein Beratungsdashboard kann verspätete, als veraltet markierte Beobachtungen tolerieren; Condition Monitoring darf alte oder Bad-qualifizierte Daten nicht stillschweigend ersetzen.
Einheitendrift: Ein Lieferant ändert bar zu kPa oder lässt die Einheit weg. Gegenmaßnahme: fehlende Einheiten ablehnen, Quell- und kanonische Einheit speichern, Umrechnungs-Testvektoren fordern.
Identitätsdrift: Ein SPS-Programm verwendet einen Tag für ein Ersatz-Asset wieder. Gegenmaßnahme: Beobachtungen an eine Asset-Lebenszyklus-ID statt an einen Anzeigenamen binden; Remapping nur mit Freigabe.
Zeitstempelmehrdeutigkeit: Quellzeit ist Lokalzeit, setzt sich nach Neustart zurück oder kommt nach dem Ereignis. Gegenmaßnahme: Quell- und Eingangszeit mit Zeitbasis speichern; auf Skew alarmieren sowie Recovery und Replay testen.
Qualitätswäsche: Ein Adapter übersetzt herstellerspezifische Unsicherheit zu Good. Gegenmaßnahme: Quell-zu-Vertrag-Qualitätsmapping führen, rohen StatusCode bewahren und unfreigegebene Mappings blockieren.
Zustandsblindheit: Training behandelt Stillstand, Kalibrierung oder manuellen Override als Normalbetrieb. Gegenmaßnahme: Maschinenzustand verpflichtend machen und Einschlussregeln pro Use Case definieren.
AAS ist die semantische Schnittstelle, nicht der Data Lake
Nutzen Sie die AAS dort, wo sie eine kontrollierte, auffindbare Schnittstelle schafft: Asset-Identität, Submodellsemantik, Data-Specification-Referenzen, Einschränkungen, Verantwortliche und Vertragsversion. Das IDTA-Metamodell empfiehlt semantische Identifikatoren für Submodellelemente und erlaubt unabhängig versionierbare Aspektansichten. Kopieren Sie nicht jede hochfrequente Messung in die AAS. Halten Sie hochratige Telemetrie in Event- oder Historian-Pfaden und verknüpfen Sie Semantikvertrag und Provenienz.
Der Data Act nennt schlechtes Metadatenmanagement sowie fehlende semantische und technische Interoperabilität als Hindernisse für Datenaustausch. Das ist ein Engineering-Signal, keine Rechtsbewertung für ein konkretes Werk. Rechtsfragen – ob eine Partei Data Holder ist, welcher Zugang geschuldet ist und welche sektorspezifischen oder vertraglichen Regeln gelten – gehören zur Prüfung durch Rechtsberatung. Engineering kann Zugang, Zweck, Provenienz und Schnittstellen bereits jetzt explizit machen.
Was dieser Ansatz nicht löst
Ein sauberer Vertrag beweist weder Modellgüte noch funktionale Sicherheit, klärt keine Datenrechte und harmonisiert keine konkurrierenden Produktstammdaten. Er kostet Engineering-Aufwand: kanonische IDs und Qualitätsmappings brauchen Ownership; strikte Validierung kann zunächst mehr Quarantänefälle erzeugen; parallele Versionen schaffen temporären Betriebsaufwand. Diese Kosten sind meist geringer als die nachträgliche Erkenntnis, dass ein Modell auf nicht vergleichbaren Signalen trainiert wurde.
Ein praktischer erster Workshop
Wählen Sie einen begrenzten Use Case und eine Asset-Familie. Inventarisieren Sie zehn hochwertige Signale; dokumentieren Sie die Vertragsfelder; mappen Sie OPC-UA-Quellen und Qualitätszustände; definieren Sie kanonische Einheiten und zulässige Maschinenzustände; implementieren Sie einen Quarantäne-Grundcode; spielen Sie eine Woche Proben durch einen neuen Consumer; veröffentlichen Sie danach die Schnittstelle als AAS-verknüpften Vertrag. Wenn Ihre OT-KI-Initiative zusätzlich einen Schutzrahmen für den Datenpfad braucht, beginnen Sie mit der Trennung von Beobachtung, Inferenz und Steuerung bevor Sie Zugriffe erweitern. Ein fokussierter Architektur-Review kann fehlende Verantwortlichkeiten, Versionen und Fehlertests vor dem Anschluss des ersten Modells sichtbar machen.
