Digitaler Zwilling

Der digitale Zwilling ist die Analyse-Engine innerhalb des Mirox-Agent, die die Messwerte Ihrer Anlage in Einblicke zu Komponentengesundheit, Verlusten, Konfiguration und Abrechnung verwandelt. Er empfängt Metriken vom Data Scraper, hält ein In-Memory-Modell der Komponentenhierarchie jeder Anlage vor, wendet physikbasierte Modelle auf historische Daten an und meldet seine Erkenntnisse zurück an die Plattform.

Der digitale Zwilling analysiert heute Solar-Photovoltaikanlagen (PV). Die Wind- und Batterieanalyse ist geplant – diese Anlagentypen können bereits Daten aufnehmen, der digitale Zwilling analysiert sie jedoch noch nicht.

Zweck und Rolle

Der digitale Zwilling verfolgt einen klar umrissenen Zweck: das Verhalten jeder Komponente verstehen und betriebliche Probleme erkennen. Er wandelt Rohmesswerte in umsetzbare Einblicke um, ohne eigene persistente Speicherung.

Kernaufgaben:

Metrik-Updates vom Data Scraper empfangen
Historische Daten aus der Zeitreihendatenbank für Analysefenster abrufen
Ein In-Memory-Modell der Komponentenhierarchie der Anlage aus der IoT Cloud aufbauen
Die Konfiguration jedes Strings erkennen und validieren (Ausrichtung, Modulanzahl, Wechselrichter-Clipping, Verschattung, Performance)
Die Komponentengesundheit nächtlich überwachen, den Zustand jeder Komponente klassifizieren und Kommunikationslücken von echten Ausfällen unterscheiden
Energieverluste mit einer Konfidenzbewertung für jeden Wert berechnen
Jedes Curtailment rekonstruieren und die entschädigungsfähige entgangene Energie sowie ihren Geldwert nach den offiziellen rechtlichen Abrechnungsverfahren berechnen
Ergebnisse und Ereignisse zurück an die IoT-Cloud-Plattform veröffentlichen, damit Betreiber sie einsehen können
Den Speicher nach Abschluss der Verarbeitung leeren

Diese Trennung hält den digitalen Zwilling auf die Analyse fokussiert, während Datenerfassung und Langzeitspeicherung an anderer Stelle stattfinden.

Drei Analyse-Engines

Der digitale Zwilling betreibt drei unterschiedliche Engines mit verschiedenen Auslösern und Zielen – ihre Trennung erklärt, warum manche Einblicke sofort erscheinen und andere sich über mehrere Nächte aufbauen.

Engine	Was sie bestimmt	Wann sie läuft
Konfigurationsanalyse	Erkannte Ausrichtung, Modulanzahl, Wechselrichter-Clipping, Verschattung und Performance jedes Strings	Automatisch – wöchentlich pro Anlage (nächtlich bei frisch angebundenen Anlagen), zusätzlich beim Start und auf Anforderung
Watchdog	Komponentengesundheitszustände, echte Ausfälle vs. Kommunikationslücken und Energieverluste	Automatisch – nächtlich pro Anlage, mit Backfill
Curtailment-Abrechnung	Die entschädigungsfähige entgangene Energie (Ausfallarbeit) jedes Curtailments und ihr Geldwert nach den offiziellen rechtlichen Verfahren	Automatisch – nächtlich pro Anlage, pro Liefermonat

Warum Einblicke Zeit brauchen

Eine frisch angebundene Anlage benötigt mehrere Nächte mit Watchdog-Läufen, bevor sich ihr Erwartungsproduktionsmodell auf das reale Verhalten jeder Komponente kalibriert. Frühe Werte stabilisieren sich in den ersten Tagen.

Architekturüberblick

Der digitale Zwilling arbeitet als asynchroner Dienst, der Metriken verarbeitet, sobald sie eintreffen:

Zentrale Architekturprinzipien:

Pro Anlage: Jeder Agent betrachtet eine Anlage als Komponentenbaum und bewertet pro Komponente und pro Ebene
Zustandslos: Keine Analyseergebnisse werden lokal gespeichert – Daten werden im Speicher verarbeitet und nach Abschluss geleert
Physikbasiert: Branchenübliche Modelle (kein maschinelles Lernen) simulieren die erwartete Produktion und vergleichen sie mit der Realität
Selbstkalibrierend: Eine Rückkopplungsschleife stimmt das Erwartungsproduktionsmodell über ein gleitendes Fenster auf jede Komponente ab
Auf Anforderung und geplant: Konfigurationsanalyse und Gesundheitsüberwachung laufen beide automatisch nach eigenen Zeitplänen; die Konfigurationsanalyse kann zusätzlich auf Anforderung ausgelöst werden

Kernkomponenten

Datenverarbeitung

Der digitale Zwilling verarbeitet Daten auf Anforderung ohne persistente Speicherung:

Datenquellen:

Webhook: Empfängt Echtzeit-Metrik-Updates vom Data Scraper
Zeitreihendatenbank: Ruft historische Daten für Analysefenster ab
IoT Cloud: Lädt Park-Struktur und Komponentenkonfiguration

Verarbeitungsablauf:

Webhook-Auslöser oder API-Anfrage startet die Verarbeitung
Park-Struktur aus der IoT Cloud in den Speicher laden
Erforderliche historische Daten aus der Zeitreihendatenbank abrufen
Per Webhook gelieferte Echtzeitmetriken empfangen oder verwenden
Analyse im Speicher durchführen
Ergebnisse an die IoT Cloud veröffentlichen
Speicher leeren – keine Daten werden persistiert

Webhook-Integration:

Empfängt Metrik-Updates vom Data Scraper per HTTP POST
Metriken werden während der Analyseausführung im Speicher verarbeitet
Keine persistente Metrik-Speicherung innerhalb des digitalen Zwillings

Konfigurationsanalyse

Die Engine zur Konfigurationsanalyse erkennt und validiert, was jeder String tatsächlich ist, und arbeitet sich von unten in der Hierarchie nach oben (String, dann Generatoranschlusskasten, Wechselrichter und Einspeisezähler). Sie läuft automatisch nach eigenem Zeitplan – einmal pro Woche für jede Anlage und im ersten Monat nach dem Onboarding einer Anlage jede Nacht – sowie einmal beim Start für den Vortag, und kann zusätzlich auf Anforderung für einen gewählten Datumsbereich ausgelöst werden.

Was sie erkennt (pro String):

Ausrichtung – der Modul-Azimut, mit Kennzeichnung von Abweichungen vom konfigurierten Wert
Modulanzahl – die tatsächliche Anzahl funktionierender Module, das Aufdecken fehlender oder defekter Module
Wechselrichter-Clipping – wenn die DC-Leistung die AC-Kapazität des Wechselrichters übersteigt, mit Clipping-Dauer und verlorener Energie
Verschattung – die Reihenverschattungsphasen bei Sonnenauf- und -untergang und der daraus resultierende Verlustanteil
Performance – gemessene gegenüber simulierter Energie und eine Performance-Ratio für den String

Jedes Ergebnis trägt einen Zuverlässigkeitsstatus, sodass ein Betreiber erkennen kann, ob eine Erkennung zuverlässig war, auf zu wenigen Daten beruhte, Werte außerhalb physikalischer Grenzen erreichte oder überhaupt keinen Strom feststellte (was einen String als ungenutzt markieren kann).

Heute nur Solar

Die obigen Konfigurationsanalysen gelten für Solar-PV-Strings. Eine Modul-Neigungserkennung wird zwar referenziert, ist aber noch nicht implementiert, und es gibt keine Konfigurationsanalyse für Wind- oder Batterieanlagen.

Branchenübliche physikalische Modelle

Der digitale Zwilling verwendet peer-reviewte physikalische Modelle statt maschinellen Lernens – zum Beispiel ein Clear-Sky-Einstrahlungsmodell und ein Eindiodenmodell für Solarmodule. Die erwartete Ausgabe wird aus Physik und Standortgeometrie berechnet und anschließend mit der tatsächlich erzeugten Produktion der Anlage verglichen.

Watchdog

Die Watchdog-Engine überwacht die Komponentengesundheit, trennt echte Ausfälle von Kommunikationslücken und berechnet Energieverluste. Anders als die Konfigurationsanalyse läuft sie automatisch jede Nacht für jede Anlage.

Nächtliche automatische Terminierung:

Jede Anlage wird einmal pro Nacht zu einem stabilen Zeitpunkt zwischen 00:00 und 03:00 UTC bewertet, gestaffelt, damit nicht alle Anlagen gleichzeitig laufen
Eine Anlage tritt dem nächtlichen Zeitplan bei, sobald genügend ihrer Strings die Konfigurationsanalyse abgeschlossen haben
Bei ihrem ersten Lauf füllt der Watchdog die Historie nach (bis zu etwa 180 Tage), sodass Sie Einblicke für den Zeitraum vor Beginn der Überwachung erhalten
Das System verfolgt, welche Tage es bereits verarbeitet hat, und ergänzt fehlende Tage in späteren Nächten – es heilt sich selbst ohne manuelles Eingreifen

Gesundheitsbewertung:

Für jede Komponente simuliert der Watchdog die Produktion, die Sie hätten sehen sollen, und vergleicht sie mit dem Messwert
Komponenten werden in klare Zustände eingeordnet: normal produzierend, degradiert, überproduzierend, keine Daten, festsitzender Logger, inaktiv sowie mehrere abgeleitete Zustände für Komponenten, deren Daten fehlen, deren Gesundheit sich aber aus den Nachbarn ableiten lässt
Ein Top-Down-Durchlauf leitet den Status von Komponenten mit fehlenden Daten aus ihrem Übergeordneten ab: ein fehlender Wechselrichter, dessen Übergeordnetes als gesund angezeigt wird, wird korrekt als Kommunikationsproblem, nicht als Ausfall markiert

Referenzeinstrahlung ohne Sensor:

Der Watchdog leitet eine gemessene Einstrahlungs-Baseline aus den am besten produzierenden Strings ab, sodass eine genaue Überwachung keinen Einstrahlungssensor vor Ort erfordert
Das Vorhandensein dieser Referenz-Baseline für einen Tag ist für das System der Beleg dafür, dass dieser Tag verarbeitet wurde

Selbstkalibrierung (Performance-Rückkopplungsschleife):

Ein Korrekturfaktor pro Komponente wird über ein gleitendes Fenster trainiert, sodass die simulierte erwartete Produktion dem realen Verhalten jeder Komponente folgt
Sie lernt nur von gesunden Komponenten und nur an Tagen mit normalem Wetter – ungewöhnliche Tage (starke Bewölkung, Schnee, Störungen) werden übersprungen, damit schlechte Daten das Modell nie vergiften
Das ist der Grund, warum sich die Vergleiche zwischen erwarteter und tatsächlicher Produktion in den ersten Tagen der Lebensdauer einer Anlage schärfen

Verlusterkennung mit Konfidenz:

Der Energieverlust wird pro Intervall als Defizit der gemessenen Produktion gegenüber der simulierten Produktion berechnet und wird nie negativ
Jede Verlustkennzahl wird mit der Konfidenz HOCH, MITTEL oder NIEDRIG versehen, und die Kategorien summieren sich zum Gesamtwert – so wissen Sie, wie sehr Sie jedem Wert vertrauen können
Ein konstanter (wiederholter) Energiemesswert wird untersucht: setzte sich die Produktion durch eine kurze Lücke hindurch eindeutig fort, wird sie als Kommunikationsausfall behandelt und vom Verlust ausgeschlossen; stoppte die Produktion, wird sie als echter Ausfall gezählt
Wetterphasen – Schnee, Tau, Nebel sowie netz- oder externe Abschaltungen – werden für alle Komponenten ausgeschlossen, sodass Wetter nie fälschlich als Komponentenfehler gewertet wird

Kommunikationslücken sind keine Verluste

Wenn eine übergeordnete Komponente gesund ist, die Daten eines Untergeordneten aber fehlen, meldet der Watchdog ein Datenerfassungsproblem, keinen Produktionsverlust. Das verhindert, dass ein vorübergehend offline gegangener Logger mit verlorener Energie verwechselt wird.

Curtailment-Abrechnung

Wenn der Netzbetreiber die Abregelung einer Anlage anordnet (negativer Redispatch nach EnWG §13a / Redispatch 2.0), hat der Betreiber Anspruch auf Entschädigung für die Ausfallarbeit – die Energie, die die Anlage produziert hätte, aber nicht produzieren durfte. Die Curtailment-Abrechnungs-Engine rekonstruiert jedes Curtailment Minute für Minute und berechnet, was der Anlage zusteht – streng nach den offiziellen Regeln, wobei jedes Ergebnis das Rechtsdokument zitiert, nach dem es berechnet wurde.

Auf Basis des offiziellen Rechtsrahmens:

Der anwendbare Beschluss wird automatisch pro Liefermonat gewählt: BilAReM (die Anlage zum BNetzA-Beschluss BK6-23-241) für Liefermonate ab Juli 2026 und sein Vorgänger BK6-20-059 Anlage 1 für frühere Monate
Curtailment durch den Netzbetreiber (Redispatch) und Curtailment durch den Vermarkter (marktbedingte Anpassung) werden getrennt und unabhängig voneinander abgerechnet – Ersteres wird gegenüber dem Netzbetreiber geltend gemacht, Letzteres betrifft den Direktvermarkter, und jedes Segment des Parks kann für sich abgerechnet werden
Der Abrechnungsfall des Parks gemäß Beschluss – Duldungsfall oder Aufforderungsfall – wird angewandt und auf jedem Ergebnis ausgewiesen

Drei Abrechnungsverfahren parallel: Welches Verfahren vertraglich bindend ist, unterscheidet sich von Anlage zu Anlage, daher berechnet und berichtet die Engine stets alle drei nebeneinander:

Spitzabrechnung („Spitz“) – das präzise Verfahren mit den parkeigenen Pyranometern: Der nächstgelegene saubere, unabgeregelte Referenztag (Vergleichszeitraum) liefert das Verhältnis von Produktion zu Einstrahlung der Anlage, das auf die während des Curtailments tatsächlich gemessene Einstrahlung skaliert wird
Vereinfachte Spitzabrechnung („Spitz light“) – die vereinfachte Variante desselben Verfahrens, mit auf die Modulebene umgerechneter Satelliteneinstrahlung
Pauschalverfahren – das pauschale Verfahren nach dem BDEW-Leitfaden: Die unmittelbar vor Beginn des Curtailments gemessene Einspeisung wird als Baseline eingefroren und innerhalb der gesetzlich definierten entschädigungsfähigen Zeitfenster angewandt

Von der Energie zum Geld: Die entgangene Energie wird mit dem offiziellen viertelstündlichen Mischpreis bewertet (einer Mischung aus dem Preisindex ID1 und dem Ausgleichsenergiepreis reBAP). Da die offiziellen Preise erst rund zwei Monate nach der Lieferung veröffentlicht werden, sind die Werte bis zum Eintreffen der offiziellen Preise als Schätzung gekennzeichnet, und die Negativpreis-Regeln des EEG §51 werden für jede Inbetriebnahme-Kohorte parallel mitberechnet.

Ereignisse tragen die vollständige Fallakte: Alles, was für eine Abrechnung relevant ist, steht an den Ereignissen selbst –

Jede Curtailment-Episode erscheint innerhalb von Minuten live als Ereignis Erkanntes Curtailment: Zeitfenster, Begrenzungsniveau und Quelle
Jedes abgerechnete Curtailment erhält ein Abrechnungsereignis mit Zeitfenster und Liefermonat, dem rechtlichen Verfahren samt Dokumentenzitat, dem Abrechnungsfall, dem gewählten Referenztag (einschließlich der näher liegenden, aber verworfenen Kandidatentage mit Begründung), der entgangenen Energie pro Verfahren in kWh, dem Geldwert mit seinem Status Schätzung/offiziell, Diagnose-Flags und einer Klartext-Erläuterung, die genau erklärt, wie der Wert zustande kam
Ein monatliches Abrechnungsereignis weist den Wert jedes Monats in EUR pro Verfahren aus, und Revisionsereignisse halten spätere offizielle Preiskorrekturen fest – die Historie wird nie überschrieben
Ereignisse wechseln von vorläufig zu endgültig, sobald sich Messwerte und Preise festigen, entsprechend der rechtlich bindenden Korrekturfrist

Steuerung durch den Betreiber: Autorisierte Benutzer können ein erkanntes Curtailment von der Abrechnung ausschließen („ignorieren“) oder Curtailments manuell mit gestuften Begrenzungsprofilen erfassen – beides umkehrbar bis zur gesetzlichen Korrekturfrist des Monats.

Konservativ aus Prinzip

Ein abgerechneter Wert ist gefordertes Geld, daher erfindet die Engine niemals Daten: Fehlende Messwerte werden übersprungen und markiert statt geraten, und wo das rechtliche Verfahren keine Antwort liefern kann – zum Beispiel wenn kein sauberer Referenztag existiert – enthält sich die Engine ausdrücklich und hinterlässt einen sichtbaren offenen Fall, denn der rechtliche Weg ist dann die förmliche Abstimmung/Clearing mit dem Netzbetreiber.

Cloud-Synchronisation

Der digitale Zwilling ist in die IoT-Cloud-Plattform integriert:

Park-Struktur-Synchronisation:

Der Park Tree ruft die Komponentenkonfiguration aus der IoT Cloud ab
Automatische Aktualisierungen, wenn Komponenten hinzugefügt oder neu konfiguriert werden
Die Komponentenerkennung synchronisiert zurück in die Cloud (Wechselrichter, Strings usw.)
Konfigurationsänderungen machen zwischengespeicherte Analyseergebnisse ungültig

Ergebnisberichterstattung:

Analyseergebnisse werden per REST-API an die IoT Cloud übermittelt
Ereignisbenachrichtigungen bei Ausfällen und Degradation
Performance-Metriken werden für die historische Nachverfolgung gespeichert
Statusaktualisierungen zur Komponentengesundheit

Betriebsmodus:

Erfordert für den Normalbetrieb Konnektivität zur IoT Cloud
Die Zeitreihendatenbank wird für die Analyse historischer Daten benötigt