MiroxMirox
  • Plattform

    • Philosophie
    • Plattform-Übersicht
    • Plattform-Ressourcen
  • Mirox-Cloud

    • Cloud-Übersicht
    • Verbundene Microservices
  • Mirox-Agent

    • Agent-Übersicht
    • Bereitstellungsoptionen
    • Data Scraper
    • Digital Twin
  • Technische Details

    • Metriksammlung
  • Information

    • Unterstützte Anlagen
  • Anlagentypen

    • Solaranlagen
    • Windanlagen
    • Batteriespeicher
  • Überwachung & Visualisierung

    • Echtzeit-Monitoring
    • Digitaler Zwilling
    • Komponentenzustände
    • Verlusterkennung
    • Effizienzerkennung
    • KPI-Dashboard
  • Datenverwaltung

    • Ereignisse
    • Tickets
    • Prognosen
    • Berichte
  • Integration & Freigabe

    • Kooperationen
    • API-Tokens
    • VPN
    • Proxy
  • KI

    • KI-Assistent & Wizards
    • Agentischer Zugriff (MCP)
  • Abrechnung

    • Markt & Tarife
    • Buchhaltung & Abrechnung
  • Kollaboration

    • Einladungen
  • Sicherheit

    • Authentifizierung
    • Berechtigungssystem
    • Kooperationsbeschränkungen
    • Zugriffs-Audit-Logging
  • Knoten

    • mrxnode
  • Anwendung

    • Türsteuerung
    • Generisches Relais
  • Edge-Cluster

    • Orchestrierung
  • Erste Schritte

    • Erste Schritte
  • Persönlich

    • VPN verwenden
    • Proxy verwenden
    • Zwei-Faktor-Authentifizierung
    • Sitzungen
    • API-Tokens
  • Pro Anlage

    • Kontakte
    • Netzwerkgeräte
    • Datenlogger
    • Komponenten
    • Direktes VPN (pro Agent)
  • Organisation

    • Mitgliederberechtigungen
    • Kooperationen
    • Dateispeicher
  • Datenexport

    • Export-Metrik-API
    • MiroxQL-Abfragesprache
    • Externe Berichterstellung
    • Grafana
    • API-Überblick
  • Unterstützung

    • Integrationsleitfaden anfordern
  • mrxnode

    • Übersicht
    • Anleitungen
    • Container-Bereitstellung
    • Befehlsreferenz
    • Fehlerbehebung
  • Berichterstellung

    • Externer Berichtgenerator
  • English
  • Deutsch
  • Español
  • Français
  • Português
  • Italiano
  • English
  • Plattform

    • Philosophie
    • Plattform-Übersicht
    • Plattform-Ressourcen
  • Mirox-Cloud

    • Cloud-Übersicht
    • Verbundene Microservices
  • Mirox-Agent

    • Agent-Übersicht
    • Bereitstellungsoptionen
    • Data Scraper
    • Digital Twin
  • Technische Details

    • Metriksammlung
  • Information

    • Unterstützte Anlagen
  • Anlagentypen

    • Solaranlagen
    • Windanlagen
    • Batteriespeicher
  • Überwachung & Visualisierung

    • Echtzeit-Monitoring
    • Digitaler Zwilling
    • Komponentenzustände
    • Verlusterkennung
    • Effizienzerkennung
    • KPI-Dashboard
  • Datenverwaltung

    • Ereignisse
    • Tickets
    • Prognosen
    • Berichte
  • Integration & Freigabe

    • Kooperationen
    • API-Tokens
    • VPN
    • Proxy
  • KI

    • KI-Assistent & Wizards
    • Agentischer Zugriff (MCP)
  • Abrechnung

    • Markt & Tarife
    • Buchhaltung & Abrechnung
  • Kollaboration

    • Einladungen
  • Sicherheit

    • Authentifizierung
    • Berechtigungssystem
    • Kooperationsbeschränkungen
    • Zugriffs-Audit-Logging
  • Knoten

    • mrxnode
  • Anwendung

    • Türsteuerung
    • Generisches Relais
  • Edge-Cluster

    • Orchestrierung
  • Erste Schritte

    • Erste Schritte
  • Persönlich

    • VPN verwenden
    • Proxy verwenden
    • Zwei-Faktor-Authentifizierung
    • Sitzungen
    • API-Tokens
  • Pro Anlage

    • Kontakte
    • Netzwerkgeräte
    • Datenlogger
    • Komponenten
    • Direktes VPN (pro Agent)
  • Organisation

    • Mitgliederberechtigungen
    • Kooperationen
    • Dateispeicher
  • Datenexport

    • Export-Metrik-API
    • MiroxQL-Abfragesprache
    • Externe Berichterstellung
    • Grafana
    • API-Überblick
  • Unterstützung

    • Integrationsleitfaden anfordern
  • mrxnode

    • Übersicht
    • Anleitungen
    • Container-Bereitstellung
    • Befehlsreferenz
    • Fehlerbehebung
  • Berichterstellung

    • Externer Berichtgenerator
  • English
  • Deutsch
  • Español
  • Français
  • Português
  • Italiano
  • English
  • Überwachung & Visualisierung

    • Echtzeit-Überwachung
    • Digitaler Zwilling
    • Komponenten-Zustände
    • Verlusterkennung
    • Effizienzerkennung (PRRC)
    • Lokaler Netzwerk-Inspektor
    • Zugriffs-Monitoring
    • KPI-Dashboard
    • Diagrammvisualisierung
  • Datenverwaltung

    • Ereignisse
    • Tickets
    • Prognosen
    • Berichte
  • Integration & Freigabe

    • Kooperationen
    • API-Tokens
    • VPN
    • Proxy (Web-Zugriff auf Anlagengeräte)
  • KI

    • KI-Assistent & Wizards
    • Agentischer Zugriff (MCP)
  • Abrechnung

    • Markt & Tarife
    • Buchhaltung & Abrechnung
  • Kollaboration

    • Einladungen
  • Sicherheit

    • Authentifizierung
    • Berechtigungssystem
    • Berechtigungsbeschränkungen für Kooperationen
    • Zugriffs-Audit-Protokollierung

Verlusterkennung

Das Watchdog-Überwachungssystem des Digitalen Zwillings erkennt nicht nur Komponentenzustände, sondern berechnet auch präzise Energieverluste für Ihre Anlagen. Die Verlusterkennung hilft Ihnen zu verstehen, wie viel Energie eine Komponente im Vergleich zur erwarteten Produktion verloren hat.

Allgemeine Konzepte

Grundprinzip der Verlusterkennung

Die Verlusterkennung vergleicht die tatsächlich produzierte Energie mit der erwarteten Energie auf Basis von Wetterdaten und Anlagenkonfiguration:

  • Erwartete Energie: Berechnet durch Simulation auf Basis von Umgebungsbedingungen und Komponentenspezifikationen
  • Gemessene Energie: Tatsächliche Produktion gemäß Energiezählern
  • Verlust: Die Differenz, wenn die gemessene Energie geringer als erwartet ist
Verlust = max(0, Erwartete Energie - Gemessene Energie)

Wann werden Verluste berechnet?

Das System berechnet Verluste nur unter bestimmten Bedingungen, um Fehlalarme zu vermeiden:

Verluste WERDEN berechnet für:

  • Komponenten mit erheblicher Unterproduktion: Wenn die gemessene Energie deutlich unter der Simulation liegt
  • Während erkannter Ausfallzeiten: Während tatsächlicher Produktionsausfälle
  • Bei zuverlässigen Daten: Messungen müssen physikalisch plausibel und konsistent sein

Verluste werden NICHT berechnet für:

  • Kommunikationsausfälle: Wenn Datenlogger keine Daten senden, die Produktion aber weiterlief
  • Ungünstige Wetterbedingungen: Unter Bedingungen, die Messungen unzuverlässig machen
  • Zeiten ohne erwartete Produktion: Wenn aufgrund der Umgebungsbedingungen keine Energie erwartet wird
  • Unzuverlässige Messungen: Wenn Messungen physikalisch unmöglich oder inkonsistent sind

Klassifizierung von Zeiträumen

Das System analysiert Energiezeitreihen und klassifiziert jeden Zeitraum:

KlassifizierungBeschreibungVerlustberechnung
Potenzieller AusfallDie Energie hat sich nach einer Datenlücke nicht erholt. Wahrscheinlich ein echter AusfallJa – Verluste werden gezählt
DatenlückeDie Energie hat sich nach einer Datenlücke erholt. Die Komponente produzierte weiter, nur die Kommunikation war unterbrochenNein – Zeitraum wird ausgeschlossen
DatenerfassungsproblemEine übergeordnete Komponente meldet gesunde Produktion, aber die Daten einer untergeordneten Komponente fehlen oder sind unplausibel. Dies ist ein Kommunikations- oder Logging-Problem, kein EnergieverlustNein – Zeitraum wird ausgeschlossen
GrenzbedingungenUngünstige Wetterbedingungen machen die Analyse unzuverlässigNein – Zeitraum wird ausgeschlossen
Normale ProduktionKontinuierliche Daten ohne LückenNur für Kandidaten – Verluste werden für unterproduzierende Komponenten berechnet

Datenerfassungsproblem vs. echter Verlust

Eine häufige Quelle der Verwirrung ist eine untergeordnete Komponente (zum Beispiel ein String), deren Daten fehlen, während die übergeordnete Komponente (der Wechselrichter) deutlich gesunde Produktion zeigt. Das System erkennt dieses Muster: Wenn die gemessene Energie des Wechselrichters damit konsistent ist, dass seine Strings normal produzieren, werden die fehlenden String-Daten als Datenerfassungsproblem behandelt – ein Logger- oder Kommunikationsproblem – und niemals als Energieverlust gezählt.

Warum das wichtig ist

Sie werden nicht durch Phantomverluste alarmiert, jedes Mal wenn ein einzelner Logger ausfällt. Nur wenn die Indizien auf tatsächlich verlorene Produktion hindeuten – die eigenen Zahlen der übergeordneten Komponente bestätigen den Minderertrag – wird ein Verlust erfasst.

Beispiel: Kommunikationsausfall vs. echter Ausfall

Szenario A: Kommunikationsausfall (DATA_GAP)

Zeit:            08:00    [Lücke]  12:00
Energiezähler:   100 kWh    ???      180 kWh
                    │                  │
                    └──────────────────┘
                    Großer Sprung: +80 kWh

Erwartete Energie während der Lücke: 100 kWh
Verhältnis: 80/100 = 80% ≥ 50% Schwellenwert

→ DATA_GAP: Komponente produzierte, nur die Kommunikation war unterbrochen
→ Dieser Zeitraum wird von der Verlustberechnung AUSGESCHLOSSEN

Szenario B: Echter Ausfall (POTENTIAL_OUTAGE)

Zeit:            08:00    [Lücke]  12:00
Energiezähler:   100 kWh    ???      105 kWh
                    │                  │
                    └──────────────────┘
                    Kleiner Sprung: +5 kWh

Erwartete Energie während der Lücke: 100 kWh
Verhältnis: 5/100 = 5% < 50% Schwellenwert

→ POTENTIAL_OUTAGE: Wahrscheinlich ein echter Ausfall
→ Verluste werden für diesen Zeitraum BERECHNET

Konfidenzstufen

Jeder berechnete Verlust erhält eine Konfidenzstufe, die angibt, wie sicher das System ist, dass es sich um einen echten Verlust handelt:

KonfidenzstufeBedeutungTypische Szenarien
HIGHSehr wahrscheinlich ein echter Verlust. Daten sind konsistent und vollständig• Kontinuierliche Unterproduktion
• Konsistente Messungen über alle Ebenen
• Keine Datenlücken
MEDIUMWahrscheinlich ein echter Verlust, aber mit einer gewissen Unsicherheit• Verluste während POTENTIAL_OUTAGE-Zeiträumen
• Grenzwertige Datenkonsistenz
• Geringfügige Inkonsistenzen
LOWMöglicher Verlust, aber erhebliche Unsicherheit. Könnte ein Datenproblem sein• Widersprüchliche Messungen
• Unklare Ausfallsituationen
• Grenzwertige Abweichungen

Grenzbedingungen

Bestimmte Umgebungs- und Wetterbedingungen machen die Verlustanalyse unzuverlässig. Diese Zeiträume werden für ALLE Komponenten ausgeschlossen:

Ausgeschlossene Bedingungen:

BedingungGrund
Ungünstige WetterbedingungenSchnee, Tau, Nebel oder andere Bedingungen reduzieren die Produktion, sind aber keine Komponentenprobleme
NetzwerkausfälleDie Kommunikationsinfrastruktur ist ausgefallen und betrifft alle Komponenten
WartungsarbeitenGeplante Abschaltungen oder Wartung

Warum globale Ausschlüsse?

Diese Bedingungen betreffen alle Komponenten gleichzeitig und sind keine komponentenspezifischen Probleme. Wird beispielsweise Schnee erkannt, wird dieser Zeitraum für alle Komponenten von der Verlustberechnung ausgeschlossen, selbst wenn einzelne Komponenten geringe Produktion zeigen.


Verlusterkennung für Solarparks

Für Solarparks verwendet das System eine mehrstufige Analyse entlang der Energiekette: von einzelnen Strings über Wechselrichter bis zum Netzeinspeisezähler.

Hierarchische Verlustberechnung

Verluste werden auf String-Ebene berechnet und nach oben aggregiert:

String → GAK → Wechselrichter → Einspeisezähler

Wichtige Prinzipien:

  • Verluste werden primär auf String-Ebene berechnet
  • Übergeordnete Komponenten = Summe der untergeordneten Komponenten
  • Wenn String-Daten unzuverlässig sind, werden sie übersprungen
  • Das System validiert, dass die String-Verluste nicht die physikalisch möglichen Verluste des Wechselrichters überschreiten

Beispiel: Hierarchische Konsistenz

Wechselrichter:
  Simulation: 10.000 Wh
  Messung:     9.000 Wh
  Max. Verlust: 1.000 Wh

String 1:                    String 2:
  Verlust: 500 Wh            Verlust: 500 Wh

Summe: 1.000 Wh = Max. Verlust Wechselrichter ✓

→ Konsistent: String-Verluste entsprechen dem Wechselrichter-Verlust

Solarpark-spezifische Grenzbedingungen

Für Solarparks werden zusätzliche wetterspezifische Ausschlüsse angewendet:

Tag mit morgendlichem Schnee:
Zeit   | Schnee | Verlustberechnung
-------|--------|------------------
06:00  | 0 cm   | Normal berechnen
07:00  | 2,5 cm | AUSGESCHLOSSEN
08:00  | 3,1 cm | AUSGESCHLOSSEN
09:00  | 1,8 cm | AUSGESCHLOSSEN
10:00  | 0 cm   | Normal berechnen

→ 07:00-09:00 für ALLE Komponenten ausgeschlossen
→ Selbst wenn ein String geringe Produktion zeigt, wird kein Verlust gezählt

Spezielle Szenarien für Solarparks

Wechselrichterausfall mit String-Datenlücken

Wenn ein Wechselrichter ausfällt, können die String-Datenlogger ausfallen. In diesem Fall:

  1. Während des Ausfalls: ALLE Strings werden einbezogen (nicht nur Kandidaten)
  2. Nach dem Ausfall: Nur Strings mit durchgängig schlechter Leistung werden als Verluste gezählt
  3. Vorteil: Verhindert, dass Verluste aufgrund von Logger-Ausfällen übersehen werden

Zählerkorruption nach Ausfällen

Manchmal bleiben String-Zähler nach einem Wechselrichterausfall hängen:

String-Energiezähler:
07:00  →  5000 Wh    (Normal)
07:45  →  5000 Wh    (Wechselrichterausfall, Logger fällt aus)
10:45  →  5000 Wh    (Wechselrichter erholt sich, Logger nicht)
18:00  →  5000 Wh    (Zähler hängt)

→ String erscheint als Kandidat (geringe Tagesproduktion)
→ ABER: Nur Verluste während 07:45-10:45 gezählt
→ Nach 10:45: Keine Verluste (Zählerkorruption, kein echter Verlust)

Beispiele für Konfidenzstufen in Solarparks

Verlust mit HIGH-Konfidenz:

String X:
- Tagessimulation: 5.000 Wh
- Tagesmessung: 4.000 Wh
- Sim_err: 0,80 (20% Verlust)
- Kontinuierliche Daten, keine Lücken
- Übergeordneter Wechselrichter gesund

→ Verlust: 1.000 Wh mit HIGH-Konfidenz
→ Eindeutiger Fall von Unterproduktion

Verlust mit MEDIUM-Konfidenz:

String Y während Wechselrichterausfall:
- Ausfall von 08:00 bis 11:00
- Verluste nur während dieses Zeitraums gezählt
- Nach dem Ausfall: normale Produktion

→ Verlust: 800 Wh mit MEDIUM-Konfidenz
→ Verlust ist auf den Ausfallzeitraum begrenzt

Verlust mit LOW-Konfidenz:

String Z:
- String meldet 60% weniger als erwartet
- Aber: Wechselrichter zeigt nur 10% Verlust
- Datenflussverhältnis inkonsistent

→ Möglicher Verlust: 2.000 Wh mit LOW-Konfidenz
→ Wahrscheinlich Messproblem, kein echter Verlust

Häufige Verlustmuster in Solarparks

Kontinuierliche Unterproduktion:

  • Ein String produziert durchgängig 20-30% weniger
  • → Verlust mit HIGH-Konfidenz
  • → Mögliche Ursachen: Verschattung, Verschmutzung, defekte Module

Periodische Ausfälle:

  • String zeigt wiederkehrende Ausfallzeiträume
  • → Verlust mit MEDIUM-Konfidenz während der Ausfälle
  • → Mögliche Ursachen: Wechselrichterproblem, Netzwerkprobleme

Inkonsistente Messungen:

  • String-Verluste stimmen nicht mit Wechselrichter-Verlusten überein
  • → LOW-Konfidenz
  • → Wahrscheinliche Ursache: Messproblem, kein echter Verlust

Verlustdaten interpretieren

So bewerten Sie Verluste

  1. Konfidenzstufe prüfen: Konzentrieren Sie sich zuerst auf Verluste mit HIGH-Konfidenz
  2. Komponentenzustand ansehen: Vergleichen Sie mit Komponentenzuständen
  3. Zeitliche Muster identifizieren: Sind die Verluste kontinuierlich oder periodisch?
  4. Hierarchie validieren: Prüfen Sie bei hierarchischen Systemen (z. B. Solarparks), ob die Verluste über die verschiedenen Ebenen hinweg konsistent sind

Verwandte Verlustzuordnung

Nicht jeder Minderertrag gegenüber der erwarteten Produktion ist eine Störung. Der Edge-Agent erfasst die Abregelung separat – Produktion, an deren Lieferung Sie bewusst gehindert wurden – und ordnet sie der verantwortlichen Partei zu:

  • Vermarkter-Abregelung: Leistung auf Anweisung Ihres Direktvermarkters oder Handelspartners reduziert.
  • Netzabregelung: Leistung durch den Netzbetreiber reduziert (zum Beispiel Einspeisemanagement bei Netzengpässen).

Eine Abregelung wird erkannt, wenn eine Anlage an oder nahe ihrer Wirkleistungsgrenze gehalten wird, und die entgangene Energie wird minütlich dem Vermarkter oder dem Netz zugeordnet, anstatt als Komponentenverlust markiert zu werden. So können Sie einen defekten String von einer völlig gesunden Anlage unterscheiden, die einfach nur zur Drosselung angewiesen wurde.

Verwandte Funktionen

  • Digitaler Zwilling – das Watchdog-Überwachungssystem, das Verluste erkennt und berechnet
  • Komponentenbewertung – wie der Zustand jeder Komponente klassifiziert wird
  • Effizienzerkennung – Performance-Ratio- und String-Konfigurationsanalyse
  • Data Scraper – Edge-Analytics einschließlich Abregelungserfassung
  • Architektur des Digitalen Zwillings – technische Umsetzung
Prev
Komponenten-Zustände
Next
Effizienzerkennung (PRRC)
MIT Licensed | Copyright 2026 Mirox Verwaltungs GmbH