Digitaler Zwilling

Der digitale Zwilling ist die Analyse-Engine innerhalb des Mirox-Agent, die die Messwerte Ihrer Anlage in Einblicke zu Komponentengesundheit, Verlusten und Konfiguration 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
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.

Zwei Analyse-Engines

Der digitale Zwilling betreibt zwei 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	Manuell – beim Start (für den Vortag) und auf Anforderung
Watchdog	Komponentengesundheitszustände, echte Ausfälle vs. Kommunikationslücken und Energieverluste	Automatisch – nächtlich pro Anlage, mit Backfill

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: Die Konfigurationsanalyse läuft auf Anforderung; die Gesundheitsüberwachung läuft automatisch jede Nacht

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 wird manuell ausgelöst – einmal beim Start für den Vortag und ansonsten auf Anforderung für einen gewählten Datumsbereich.

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.

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