Wissenschaftliche Standardisierung und Data Provenance
Die Energiewirtschaft zählt zu den kritischen Infrastrukturen (KRITIS). Mit zunehmender Dezentralisierung stoßen traditionelle, silobasierte Stammdaten-Systeme an ihre Grenzen. Die Einführung von Künstlicher Intelligenz – insbesondere Agentic AI – zur automatisierten Konsistenzprüfung von Anlagenstammdaten erfordert ein neues Maß an Auditierbarkeit und Interoperabilität. Die Lösung für das sogenannte Vendor-Lock-in-Problem proprietärer Software-Silos liegt in der konsequenten Adaption wissenschaftlicher Datenstandards.
Cernion, als Referenzimplementierung für das Agentic Asset Master Data Management (a²mdm), löst diese Herausforderung architektonisch durch den FAIR Data Layer (eingeführt in v0.11 und finalisiert in v0.12).
Dieses Kapitel beleuchtet die technische Implementierung der FAIR-Prinzipien (Findable, Accessible, Interoperable, Reusable), die Integration der Open Energy Ontology (OEO) und die Sicherstellung von Data Provenance gemäß den Vorgaben des EU AI Acts für Hochrisiko-Systeme.
1. Vermeidung von Vendor-Lock-ins durch die Open Energy Ontology (OEO)
Ein zentrales Problem der Datenintegration bei Verteilnetzbetreibern ist das Fehlen eines gemeinsamen, maschinenlesbaren Vokabulars. Cernion begegnet diesem Problem durch eine native, statische Mapping-Schicht auf die Open Energy Ontology (OEO), dem Standard-Vokabular der Nationalen Forschungsdateninfrastruktur (NFDI4Energy).
Technische Umsetzung (oeo-mappings.js & sync-oeo.js):
Cernion verzichtet bewusst auf einen ressourcenintensiven, vollumfänglichen Knowledge Graph (SPARQL-Endpoint) zur Laufzeit. Stattdessen zieht ein dediziertes Entwickler-Skript (npm run sync:oeo) die aktuellste OEO-ETD-CSV von GitHub und kompiliert daraus ein hochperformantes, statisches Lookup-Modul (src/oeo-mappings.js).
Dieses Modul umfasst ca. 150 kuratierte Mappings, die präzise auf die Anforderungen im Assetmanagement (z.B. Marktstammdatenregister / MaStR) zugeschnitten sind. Beispielsweise wird das MaStR-Feld Lage bei Windkraftanlagen nicht einfach als Text verarbeitet, sondern semantisch differenziert in wind-onshore (OEO_00000446) und wind-offshore.
Semantische Anreicherung der KI (Classifier Enrichment):
Ein besonderer Architektureingriff liegt in der Nutzung der deutschen OEO-Labels (labelDe, z.B. „Umspannwerk“ oder „Solaranlage“). Diese Begriffe werden automatisiert in den Keyword-Pool der Cernion-Klassifizierungs-KI (Classifier) überführt. Dies boostet die heuristische Erkennungsrate bei unstrukturierten, deutschsprachigen Daten-Uploads von Netzbetreibern erheblich, ohne den eigentlichen Scoring-Algorithmus anpassen zu müssen.
OpenAPI-Annotationen:
Alle REST-Endpunkte (über 45 Actions in 7 Domänen wie grid-operations oder energy-market) sind via OpenAPI mit einer x-oeo-class-Erweiterung annotiert. Zusätzlich wird ein JSON-LD Endpunkt (GET /api/datapoints/oeo-context) bereitgestellt, der das Mapping von internen Cernion-Feldern auf OEO-IRIs als @context-Dokument ausliefert.
2. Data Provenance & KRITIS-Compliance (Der EU AI Act in der Architektur)
Systeme, die als Sicherheitskomponenten in der Verwaltung kritischer Infrastrukturen eingesetzt werden, unterliegen künftig den strengen Vorgaben des EU AI Acts für Hochrisiko-KI-Systeme (Art. 10, 12, 15). Die Kernanforderung lautet: Data Provenance. Es muss jederzeit kryptografisch nachweisbar sein, auf welcher Datengrundlage (Quellen, Lizenzen, Zeitstempel) ein KI-Agent eine Entscheidung (z.B. eine automatisierte Stammdaten-Korrektur) getroffen hat, um “KI-Halluzinationen” auszuschließen.
Die In-Memory-Edge-Architektur (PouchDB):
Cernion garantiert KRITIS-Compliance durch eine strikte In-Memory-Policy am Edge. Sensible Netztopologie- oder Assetdaten (z.B. im Datapoint Layer) verbleiben in der lokalen PouchDB-Instanz des Betreibers und werden nicht unmaskiert an externe Cloud-LLMs gesendet. Die Agenten operieren primär auf Basis der anonymisierten OEO-IRIs.
Der OEMetadata v2.0 Exporter (oemetadata.service.js):
Das Herzstück der Provenance-Sicherung ist der OEMetadata-Exporter (eingeführt in v0.11, strikt validiert in v0.12). Jeder verwaltete Cernion-Datenpunkt erzeugt auf Anfrage ein JSON, das exakt dem offiziellen schema.json v2.0 des OEMetadata-Projekts entspricht.
Der Exporter extrahiert dynamisch:
- Temporal & Spatial Data: Zeitreihen-Begrenzungen und Georeferenzierungen (Bounding Boxen) basierend auf den abgerufenen Datensätzen (z.B. das Netzgebiet „Ludwigshafen“).
- Sources & Licenses: Ein Cernion-Agent dokumentiert automatisch in den Metadaten, welche Microservices er abgefragt hat (
sources). Das System mappt diese auf die korrekten Quell-Lizenzen (z.B.DL-DE/BY-2.0für das MaStR oderCC-BY-4.0für ENTSO-E). - Kryptografischer Hash: Jeder Export beinhaltet einen kryptografischen Hash (z.B. SHA-256) der rohen Quelldaten zum Zeitpunkt der Agenten-Analyse, was die Auditierbarkeit für den Netzbetreiber rechtssicher macht.
Um sicherzustellen, dass keine invaliden Metadaten ausgeliefert werden, lädt das System während des Builds (npm run sync:oemetadata) das offizielle JSON-Schema von der Open Energy Platform herunter. Jede REST-Anfrage (GET /api/datapoints/:name/oemetadata?validate=true) wird zur Laufzeit via ajv validiert.
3. Orchestrierung über Systemgrenzen: Der OEP-Connector
Um KI-Agenten im Assetmanagement wirklich proaktiv handeln zu lassen, müssen sie die lokale Sicht (das eigene Netzgebiet) mit globalen Entwicklungen abgleichen können. Cernion v0.12 führt hierfür einen dedizierten, Read-Only-Connector (oep.service.js) zur Open Energy Platform (OEP) ein.
Dieser Microservice ermöglicht es dem Agent-Planner, komplexe Fragestellungen in mehrstufige Pläne (Steps) zu zerlegen.
Ein Prompt wie: “Vergleiche die installierte PV-Leistung bei den TWL Netzen mit dem Netzentwicklungsplan-Szenario (NEP) 2035” triggert nun folgende automatisierte Kette:
- Der Agent fragt den lokalen Cernion-Service (
assets.solar) für das MaStR-Netzgebiet ab. - Der Agent nutzt den OEP-Connector (
oep.query), um das öffentliche NEP-Szenario direkt aus der Datenbank der nationalen Forschungsinfrastruktur zu ziehen. - Das LLM (als Reasoning-Layer) interpretiert das Delta lokal und speichert das Ergebnis als validierten Datenpunkt zurück in die PouchDB.
Um die Latenz bei Agenten-Entscheidungen gering zu halten, werden die OEP-Tabellenmetadaten in Cernion im RAM gecacht (TTL von 24h), während die eigentlichen Tabellendaten aus Datenschutzgründen lediglich durch den Speicher fließen (Pass-through).
4. Datapoint Scheduling: Kontinuierliche Datenhygiene
Für den operativen Betrieb eines Stadtwerks reicht ein manueller Aktualisierungs-Trigger nicht aus. KI-Agenten können nur dann belastbare Konsistenzprüfungen durchführen, wenn das Daten-Fundament (“Datapoint Layer”) stets aktuell ist.
Mit v0.12 implementiert Cernion ein lokales Interval-Scheduling (strategy: "interval"). Der datapoint.service.js prüft kontinuierlich (z.B. in einem 60-Sekunden-Tick), ob Datenpunkte veraltet sind. So kann beispielsweise eine “Tägliche Portfolio-Inventur (PV, Wind, Speicher)” konfiguriert werden (intervalMinutes: 1440). Ist ein Datenpunkt veraltet, markiert der interne Health-Endpoint diesen als stale und triggert autonom einen Refresh.
(Dieser Mechanismus ist essentiell für die Vorbereitung auf Cernion v0.14+, in dem autonome Validierungsagenten kontinuierlich und unbeaufsichtigt auf der Datapoint-Schicht nach Fehlern in der Marktkommunikation oder dem MaStR suchen werden).
Investitionssicherheit durch FAIR Data
Mit der Architektur des FAIR Data Layers positioniert sich Cernion als Referenzimplementierung für das Agentic Asset-MDM. Kein anderer kommerzieller Energiedaten-Agent erzeugt aktuell vollautomatisch OEMetadata-konforme Exporte inkl. OEO-Annotationen und Data-Provenance-Hashes. Für Stadtwerke bedeutet dies: Investitionssicherheit (kein Vendor-Lock-in), lückenlose Nachvollziehbarkeit für Audits (EU AI Act) und sofortige Interoperabilität mit der nationalen Energieforschungslandschaft.
No Comments