Data Scraper

Der Data Scraper ist die zentrale Datenerfassungs-Engine innerhalb des Mirox-Agent, die aktiv Echtzeitinformationen von allen überwachten Anlagenkomponenten Ihres Parks abruft. Er verbindet sich mit Ihren Loggern, Wechselrichtern, Zählern und Batteriesystemen über eine Bibliothek herstellerspezifischer Adapter, normalisiert alles in ein einheitliches Metrik-Vokabular und leitet das Ergebnis an den Rest der Plattform weiter — während er einen wachsenden Satz von Edge-Analysen (Performance-Ratio, Curtailment-Tracking, Clear-Sky-Baselines, Prognosen und Netzwerküberwachung) sowie einen kontinuierlichen Komponentengesundheits-Watchdog direkt an der Anlage ausführt.

Zweck und Rolle

Der Data Scraper verfolgt einen einzigen, fokussierten Zweck: aktiv Rohmesswerte von Anlagenkomponenten erfassen und zur Verarbeitung weiterleiten. Er fungiert als Brücke zwischen unterschiedlichen Geräten verschiedener Hersteller und der einheitlichen Mirox-Plattform und übersetzt proprietäre Datenformate in standardisierte Metriken.

Kernverantwortlichkeiten:

• Verbindung zu Datenloggern und Überwachungsgeräten über herstellerspezifische Adapter
• Abruf von Rohmesswerten nach konfigurierbaren Zeitplänen
• Umwandlung herstellerspezifischer Daten in ein standardisiertes Metrikformat
• Automatische Erkennung und Verfolgung von Anlagenkomponenten
• Überwachung der Komponentenaktivität und des Betriebsstatus
• Kontinuierliche Überwachung von Komponentengesundheit und Verbindungsstatus sowie Auslösen von Park-Ereignissen bei Ausfällen, Messkonflikten und Verbindungsproblemen
• Ausführung von Edge-Analysen (erwartete Leistung, Performance-Ratio, Curtailment, Clear-Sky und Prognosen)
• Inspektion des lokalen Netzwerks der Anlage und Auditierung von Gerätezugriffen
• Weiterleitung von Metriken an die Zeitreihendatenbank und den Digital-Twin-Dienst
• Meldung von Komponentengesundheit und Betriebsstatus an die IoT Cloud

Diese Trennung der Zuständigkeiten hält den Data Scraper schlank, fokussiert und unabhängig deploybar.

Architekturüberblick

Der Data Scraper arbeitet als asynchroner, ereignisgesteuerter Dienst, in dem mehrere Datenerfassungs-Tasks gleichzeitig laufen:

Zentrale Architekturprinzipien:

• Keine eigene Datenbank: Kein Analysezustand überlebt Neustarts; nicht zugestellte Daten werden auf der lokalen Festplatte gepuffert, bis sie gesendet werden können
• Adapterbasiert: Ein dedizierter, herstellerspezifischer Adapter spricht das Protokoll jedes Geräts
• Selbstheilend: Automatische Fehlerbehebung mit exponentiellem Backoff
• Nebenläufig: Jede Datenquelle wird unabhängig erfasst
• Edge-deployt: Läuft an oder nahe der Anlage, nahe an den Geräten, die er ausliest

Das Adaptersystem

Konzept

Ein Adapter ist ein herstellerspezifisches Konnektormodul, das weiß, wie man mit einer bestimmten Gerätefamilie kommuniziert. Jeder Adapter wird handgebaut und gegen die eigene Web-, API- oder Datenbankschnittstelle des jeweiligen Geräts per Reverse Engineering entwickelt — es gibt keine einzelne „Spricht-jedes-Protokoll"-Engine. Das Adaptersystem ist der zentrale Erweiterungsmechanismus: Die Unterstützung eines neuen Geräts bedeutet, einen neuen Adapter hinzuzufügen, was wir auf Anfrage tun (siehe unten).

Jeder Adapter ist ein in sich geschlossenes Modul, das verantwortlich ist für:

1. Verbindungsmanagement – Aufbau und Aufrechterhaltung der Kommunikation
2. Datenabruf – Abruf von Messwerten unter Verwendung des passenden Protokolls
3. Datentransformation – Umwandlung in das standardisierte Metrikformat

Alle Adapter erben von einer Basisklasse, die Gesundheitsüberwachung, automatische Wiederholungslogik, exponentiellen Backoff bei Fehlern, Metrikvalidierung und Statusmeldungen an die IoT-Plattform bereitstellt.

Gesundheitsmanagement

Jeder Adapter implementiert einen automatischen Zustandsautomaten:

• INITIALIZING: Hochfahren und Aufbau der ersten Verbindungen
• HEALTHY: Normalbetrieb mit erfolgreichen Datenerfassungen
• UNHEALTHY: Fehler treten auf, aber der Betrieb wird fortgesetzt
• RECONNECTING: Durchführung von Wiederherstellungsmaßnahmen nach wiederholten Fehlern
• FROZEN: Das Gerät liefert veraltete Daten — dieselben Werte wiederholen sich, oder innerhalb des erwarteten Zeitfensters ist kein neuer Messwert eingetroffen
• PAUSED: Vorübergehend per Benutzerbefehl pausiert; setzt automatisch fort, wenn die Pause abläuft

Das System wechselt automatisch zwischen den Zuständen, meldet den Status an die Plattform und versucht die Wiederherstellung ohne manuellen Eingriff. Der Zustand FROZEN ermöglicht es der Plattform, einen tatsächlich ausgefallenen Logger von einem zu unterscheiden, der lediglich einen festgefahrenen Wert wiederholt.

Unterstützte Geräte

Der Data Scraper wird mit rund zwanzig herstellerspezifischen Adaptern ausgeliefert, von denen jeder für eine bestimmte Gerätefamilie gebaut wurde. Die folgende Liste spiegelt wider, was heute unterstützt wird, und wächst, sobald ein neues Gerät integriert wird.

Erstellung neuer Adapter

Es können neue Adapter entwickelt werden, um zusätzliche Geräte oder Protokolle zu unterstützen. Das modulare Design und die Funktionalität der Basisklasse verkürzen die Entwicklungszeit erheblich.

Kompatibilität mit Altgeräten: Wir können Adapter für ältere Geräte erstellen, die nie speziell für den Datenexport ausgelegt waren. Solange das Gerät seine Daten auf irgendeine zugängliche Weise bereitstellt — sei es über eine REST-API, eine Weboberfläche, eine Datenbank, ein Dateisystem oder einen beliebigen anderen Mechanismus — können wir diese Daten extrahieren und in die Plattform integrieren.

Uneingeschränkte Datenerfassung: Unsere Adapter sind nicht auf die vordefinierten Datenexportformate beschränkt, die Datenlogger typischerweise bereitstellen. Wir können alle Daten erfassen, die das Gerät verfügbar macht, und gehen damit über den Standardsatz an Metriken hinaus, den der Logger eines Herstellers möglicherweise offenlegt. Verfügt ein Gerät über zusätzliche Diagnoseinformationen, erweiterte Parameter oder verborgene Datenpunkte, die über seine Schnittstelle zugänglich sind, können wir diese abrufen und standardisieren.

Onboarding über die Plattform

Für eine Teilmenge von Geräten können Sie einen Logger über die Plattform in Betrieb nehmen, ohne von Hand eine Konfiguration zu schreiben. Ein Onboarding-Assistent fordert den Agent auf, eine Probe-Verbindung zum Gerät herzustellen, und streamt die Live-Ergebnisse der Prüfung an Sie zurück, sodass Sie sofort sehen, ob die Verbindung funktioniert, bevor Sie sie festlegen. Es gibt zwei Varianten:

• Zero-Config-Onboarding – der Adapter besitzt bereits den vollständigen Messwertsatz des Geräts, sodass der Assistent nur eine Nur-Lese-Live-Vorschau zeigt und Sie speichern. Heute verfügbar für siebzehn Gerätefamilien: Janitza-Zähler, Huawei SmartLogger, Phoenix-Contact-Controller, Fronius-Wechselrichter, Solar-Log-Datenlogger, SMA Sunny Central, SMA Power Manager, Sungrow Logger, Zebotec, Becker PV-Control (Prometheus), FREQCON-Batteriespeicher, Wattkraft Parkcontrol, NR-Electric-Batterieumrichter, Linyang/Xieneng-Container-Batterien SEG-HighPROTEC-Schutzgeräte, INTILION-scalecube-Batterien und die WAGO-PFC200-Alarmsteuerung. Mehrere davon — zum Beispiel Janitza, Fronius und Wattkraft — benötigen überhaupt keine Anmeldedaten; SMA Power Manager und Sungrow Logger werden mit Geräteanmeldedaten angebunden und melden zusätzlich automatisch ihr eigenes Geräteinventar (Komponentenliste, Seriennummern, Firmware), statt es abzufragen. Die WAGO-Alarmsteuerung ist die eine Ausnahme vom schnellen Weg: Auf dem Draht steht nicht, welches Programm eine WAGO ausführt, deshalb wird sie nie automatisch erkannt — sie wird über Logger hinzufügen angebunden, wobei Adapter und Integratorprofil von Hand gewählt werden.
• Interaktive Zuordnung für generische Logger – manche Logger stellen beliebige Rohwerte bereit, die die Plattform nicht von sich aus interpretieren kann. Für diese fordert der Assistent den Agent auf, jeden vom Gerät bereitgestellten Rohwert aufzuzählen (Gruppe, Name, Einheit, Live-Stichprobe), der Bediener ordnet jeden einer bekannten Metrik zu, und ein zuordnungsgesteuerter Probelauf zeigt vor dem Speichern eine Vorschau der genauen Metriken, die erzeugt würden. QReader und Bluelog werden auf diese Weise angebunden.

Metrik-Standardisierung

Alle erfassten Daten werden in ein standardisiertes Metrikformat umgewandelt, das durch die Metrik-Taxonomie der Plattform definiert ist. Dies gewährleistet Konsistenz über alle Datenquellen hinweg und ermöglicht eine einheitliche nachgelagerte Verarbeitung.

Metrikstruktur

Jede Metrik folgt einer standardisierten Struktur, die mit modernen Zeitreihendatenbanken kompatibel ist:

Komponenten:

• Name: Standardisierter Metrik-Bezeichner aus einer vordefinierten Taxonomie
• Wert: Numerischer Messwert in SI-Basiseinheiten
• Labels: Schlüssel-Wert-Paare zur Komponentenidentifikation und -gruppierung
• Zeitstempel: Optionale Beibehaltung des ursprünglichen Gerätezeitstempels

Standard-Labels:

• Typ und Instanznummer des Quelladapters
• Menschenlesbare Namen
• Komponentenbezeichner (Wechselrichter-ID, Stringnummer usw.)
• Physischer Standort oder Gruppierungsinformationen

Einheitenkonventionen

Alle Metriken verwenden SI-Basiseinheiten, unabhängig davon, was das Gerät des Herstellers meldet:

• Leistung: Watt (W)
• Energie: Wattstunden (Wh)
• Spannung: Volt (V)
• Stromstärke: Ampere (A)
• Temperatur: Celsius (°C)
• Einstrahlung: Watt pro Quadratmeter (W/m²)

Adapter konvertieren während der Transformationsphase automatisch von herstellerspezifischen Einheiten (kW, MWh usw.) in diese Standards.

Metrik-Kategorien

Die Plattform definiert 451 standardisierte Metriktypen, organisiert in 11 Familien:

Label-Erweiterungen (pro String, pro Phase, pro Wechselrichter usw.) vervielfachen diese in einer realen Anlage zu weit mehr einzelnen Zeitreihen. Die vollständige Metrik-Taxonomie und Definitionen finden Sie unter Metrik-Erfassung.

Datenerfassungsablauf

Polling-Strategien

Adapter unterstützen zwei Polling-Modi:

Intervallbasiert (Standard): Wird alle N Sekunden ausgeführt, nachdem die vorherige Erfassung abgeschlossen ist. Einfach und reaktionsfähig gegenüber variierenden Erfassungsdauern.

Statisch zeitbasiert: Wird in festen Intervallen ab Mitternacht mit optionalem Offset ausgeführt (z. B. um 00:01, 05:01, 10:01 bei 5-Minuten-Intervallen mit 1-Minuten-Offset). Nützlich zur Abstimmung mit externen Systemen.

Verarbeitungspipeline

Nach der Erfassung durchlaufen die Metriken mehrere Verarbeitungsstufen:

Metrikvorbereitung: Quell-Labels werden hinzugefügt, Zeitstempel angewandt und die Struktur validiert.

Filterung: Konfigurierte Filter können Werte verändern, Bereiche validieren oder Metriken anhand von Regeln überspringen.

Berechnungen: Automatisierte Kalkulatoren leiten zusätzliche Metriken ab:

• Solarstrahlungsleistung wird zu Einstrahlungsenergie integriert
• Stringspannung × Stromstärke wird zu Leistung berechnet
• Leistungswerte werden über die Zeit zu Energie integriert

Komponentenerkennung: Während die Metriken durchfließen, erkennt und identifiziert der Data Scraper automatisch Anlagenkomponenten. Dies ist eine entscheidende Funktion — da der Data Scraper die Schicht ist, die aktiv Daten erfasst, weiß er inhärent, welche Komponenten existieren und Daten liefern. Das System erkennt automatisch:

• Wechselrichter (aus Wechselrichter-Leistungsmetriken)
• String-Combiner-Boxen / GAKs (aus GAK-Metriken)
• Einzelne Strings (aus Stringspannungs-/-strommetriken)
• Einstrahlungssensoren (aus Strahlungsmetriken)
• Netzanschlusspunkte (aus Netzenergiemetriken)

Erkannte Komponenten werden zur Bestandsverwaltung mit der IoT-Plattform synchronisiert und erzeugen so ein in Echtzeit selbstpflegendes Anlagenregister ohne manuelle Konfiguration.

Produktionserkennung: Das System überwacht den Betriebszustand der Anlage:

• Erkennt anhand von Einstrahlung und Leistung, wann die Produktion beginnt
• Identifiziert unerwartete Abschaltungen während der Produktionszeiten
• Meldet Zustandsübergänge für die Alarmierung

Metrik-Gruppierung: Metriken werden nach Zeitreihe gebündelt, um die Performance des Datenbankeinfügens zu optimieren.

Datenexport

Verarbeitete Metriken werden an zwei Ziele weitergeleitet:

Zeitreihendatenbank: Metriken werden in Batches mit Ratenbegrenzung und Wiederholungslogik zur Langzeitspeicherung und historischen Abfrage übertragen.

Digital-Twin-Webhook: Ein separater Hintergrund-Task leitet kontinuierlich die neuesten Metrikwerte an den Digital-Twin-Dienst (ein völlig separater Microservice) zur Echtzeitanalyse weiter. Der Data Scraper hat keine Kenntnis davon, was der Digital Twin mit den Daten macht — er stellt lediglich die Metriken bereit. Informationen zur Digital-Twin-Verarbeitung finden Sie unter Digital Twin.

Zustandsloser Betrieb

Der Data Scraper führt keine eigene Datenbank und hält zwischen Neustarts keinen Analysezustand:

• Kann ohne Datenverlust gestoppt und neu gestartet werden
• Mehrere Instanzen können unabhängig für verschiedene Parks laufen
• Jeder Polling-Zyklus ist unabhängig von vorherigen Zyklen
• Absturzsicher, ohne Risiko, persistenten Zustand zu beschädigen
• Messwerte und Statusmeldungen, die nicht zugestellt werden können — zum Beispiel während eines Internetausfalls — werden auf der lokalen Festplatte gepuffert und automatisch zugestellt, sobald die Verbindung zurückkehrt, sodass nichts verloren geht (die unter Mirox-Agent Überblick beschriebene Resilienz „Lokale Aufbewahrung / Automatische Wiederaufnahme“)

Der einzige persistente Zustand ist der lokale Zustellungspuffer noch nicht übertragener Daten, plus das, was extern liegt:

• Konfigurationsdateien (versionskontrolliert)
• Zeitreihendatenbank (externes System)
• IoT-Cloud-Komponentenregister (externes System)

Dieses Design sorgt für betriebliche Einfachheit, Zuverlässigkeit und einfache horizontale Skalierung.

Trennung der Zuständigkeiten

Der Data Scraper hat eine eng abgegrenzte, fokussierte Verantwortung, die eine klare Abgrenzung von anderen Plattformkomponenten ermöglicht:

Data Scraper:

• Erfasst Rohmesswerte von Anlagenkomponenten
• Wandelt Daten in das Standardformat um
• Erkennt und verfolgt Komponenten
• Überwacht den Aktivitätsstatus von Komponenten
• Überwacht live die Komponentengesundheit und den Verbindungsstatus und öffnet und schließt Park-Ereignisse
• Leitet Metriken an andere Dienste weiter

Digital Twin: Validiert gegen physikalische Modelle und erkennt Anomalien und Verluste

Zeitreihendatenbank: Speichert historische Daten, stellt eine Abfrageschnittstelle bereit

IoT Cloud: Pflegt das Komponentenregister, verfolgt den Gerätestatus, verwaltet den Anlagenbestand

Diese Trennung ermöglicht die unabhängige Entwicklung, das Testen, die Bereitstellung und die Skalierung jeder Komponente, während jeder Dienst sich auf seine Kernkompetenz konzentriert.

Erweiterte Funktionen

Automatische Gesundheitsüberwachung

Jeder Adapter implementiert einen Zustandsautomaten, der die Betriebsgesundheit verfolgt, mit automatischer Meldung an die Plattform und Bereitstellung über die Metrik-API für die betriebliche Überwachung.

Automatische Komponentenerkennung

Die Position des Data Scrapers als Datenerfassungsschicht verschafft ihm einen einzigartigen Vorteil: Er weiß inhärent, welche Komponenten an einer Installation existieren, weil er direkt mit den von ihnen erzeugten Metriken interagiert. Während die Metriken durch das System fließen, werden Komponenten automatisch aus Metrik-Labels erkannt und bei der IoT-Plattform registriert.

Erkennungsprozess:

1. Metriken treffen mit identifizierenden Labels ein (Wechselrichter-ID, Stringnummer, Sensorstandort usw.)
2. Der Data Scraper extrahiert Komponenteninformationen aus diesen Labels
3. Neue Komponenten werden automatisch bei der IoT Cloud registriert
4. Komponenten-Metadaten (Typ, Bezeichner, Standort) werden synchronisiert
5. Die Plattform pflegt einen aktuellen Anlagenbestand ohne manuelle Eingabe

Dieser Selbsterkennungsmechanismus stellt sicher, dass die Plattform stets weiß, welche Anlagenkomponenten an der Installation existieren, wodurch der Bedarf an manueller Konfiguration entfällt und die Bereitstellungszeit reduziert wird.

Produktionszustandserkennung

Der Dienst überwacht den Betriebszustand der Anlage und erkennt Produktionsstarts, unerwartete Abschaltungen während der Produktionszeiten sowie Zustandsübergänge für Alarmierung und Analyse, wobei er nur dann meldet, wenn sich der Zustand tatsächlich ändert. Er achtet außerdem auf Überproduktion — Leistung oberhalb des Clear-Sky-Modells über einen anhaltenden Zeitraum —, was auf einen Logger hinweisen kann, der eingefrorene Werte liefert, und greift in diesem Fall auf das Clear-Sky-Modell zurück, damit der Datenstrom sinnvoll bleibt. Dies bietet betriebliche Echtzeitkenntnis, die über reine Rohmesswerte hinausgeht.

Berechnete Metriken

Mehrere Kalkulatoren leiten automatisch Metriken aus Rohmesswerten ab — Solarstrahlung wird zu Einstrahlungsenergie integriert, Stringleistung wird aus Spannung und Stromstärke berechnet und Leistungswerte werden über die Zeit zu Energie integriert. Diese Berechnungen erfolgen transparent und reichern den Datenstrom an, ohne eine explizite Konfiguration zu erfordern.

Edge-Analytik

Über die reine Erfassung hinaus führt der Data Scraper einen Satz von Analysen direkt an der Anlage aus, die aus dem Live-Metrik-Feed berechnet und neben den Rohdaten als darstellbare Zeitreihen exportiert werden.

Erwartete Leistung und Performance-Ratio

Der Agent berechnet kontinuierlich die erwartete Leistung für jede Anlage und vergleicht die tatsächliche Produktion damit als Performance-Ratio (PR) — ein normalisiertes Maß dafür, wie gut die Anlage verfügbares Sonnenlicht in Strom umwandelt. Statt einer einzelnen Eingangsgröße zu vertrauen, werden mehrere unabhängige Einstrahlungsquellen parallel überwacht, und jede Quelle erhält ihre eigene PR-Zeitreihe — ein driftender Sensor vor Ort kann Ihre Baseline daher nie unbemerkt verfälschen:

• Pyranometer vor Ort — die anlageneigenen Einstrahlungssensoren, nahezu in Echtzeit verfügbar
• Satellit — satellitengestützte Einstrahlung für den exakten Standort der Anlage
• Wettermodell — modellierte Einstrahlung aus meteorologischen Daten

Umrechnung in die Modulebene (POA). Alle Quellen werden in die Einstrahlung in der Modulebene (Plane of Array, POA) umgerechnet — die Einstrahlung, die tatsächlich auf die Module trifft — und zwar anhand der Komponentenhierarchie der Anlage (des Park Tree): Jeder String trägt seine eigene Ausrichtung, einen Azimutwinkel und eine Neigung, entweder vom Betreiber konfiguriert oder von der Analyse-Engine erkannt. Die horizontale Einstrahlung wird in ihren direkten und diffusen Anteil zerlegt und mit branchenüblicher Sonnenstandsphysik auf jede einzelne Modulebene transponiert, sodass Modulfelder mit unterschiedlicher Ausrichtung jeweils ihre eigene korrekte Erwartung erhalten. String-Erwartungen werden zu Combiner-Box- und Wechselrichterkurven aufsummiert und auf die AC-Nennleistung des jeweiligen Wechselrichters begrenzt.

Anomaliefilterung. Bevor ein Zeitpunkt in die vertrauenswürdige („bereinigte“) PR einfließen darf, maskiert eine Reihe von Filtern jede Situation aus, in der ein niedriges Verhältnis keinen Fehler bedeuten würde:

Eine PR pro Quelle. Die Performance-Ratio wird anschließend für jede Einstrahlungsquelle separat berechnet — veröffentlicht sowohl roh (jeder berechenbare Wert) als auch bereinigt (nur die gefilterten, vertrauenswürdigen Werte) — auf Parkebene und pro Komponente (Wechselrichter, Combiner-Box, String). Über den gleitenden Durchschnitt der bereinigten PR kalibriert sich zudem das Modell der erwarteten Leistung selbst: Die Erwartung passt sich automatisch an die reale Effizienz jeder Anlage an, und genau an dieser Erwartung misst auch der Komponentengesundheits-Watchdog die Live-Produktion.

Live-Curtailment-Tracking

Wenn eine Anlage weniger produziert, als sie könnte, ordnet der Agent die entgangene Produktion ihrer Ursache zu: Curtailment durch den Direktvermarkter (eine bewusste marktgetriebene Begrenzung) gegenüber Curtailment durch den Netzbetreiber. Diese Unterscheidung ist wichtig für die Verlustabrechnung und das vertragliche Reporting. Curtailment wird pro Minute verfolgt und sowohl als momentane Leistung als auch als kumulierte Energie ausgegeben. Wie Curtailment in die gesamte Verlustzuordnung passt, erfahren Sie unter Verlusterkennung.

Clear-Sky-Baseline und Prognose

• Clear-Sky-Baseline: eine theoretische PV-Kurve unter Idealbedingungen, die als Langzeitaufzeichnung gepflegt wird und Ihnen eine stabile Referenz zum Vergleich mit der tatsächlichen Leistung liefert.
• Day-Ahead-Prognose: eine kurzfristige PV-Produktionsprognose, die aus Wetterdaten abgeleitet wird, sodass Sie die Leistung des nächsten Tages antizipieren können. Diese basieren auf Wetterphysik, nicht auf statistischen Schätzungen.

Historisches Backfill

Wenn eine Anlage erstmals angebunden wird oder nach einer Lücke kann der Agent historische Daten nachladen (Backfill) — er spielt Rohmesswerte erneut ab und leitet die oben genannten Analysen für ein angefordertes Zeitfenster neu ab und übergibt das Ergebnis dann an die Live-Pipelines, sodass die Diagramme von Tag eins an vollständig sind, statt leer zu beginnen.

Komponentengesundheits-Watchdog

Über die Datenerfassung hinaus beurteilt der Agent kontinuierlich, ob jede produzierende Komponente — Wechselrichter, Combiner-Boxen (GAKs), Strings und Einstrahlungssensoren — tatsächlich gesund ist, und macht aus seinen Erkenntnissen Park-Ereignisse, die Sie auf der Plattform sehen. Rund um die Uhr werden zwei Fragen gestellt: Ist die Komponente noch verbunden, und produziert sie, was sie sollte?

Verbindungsüberwachung

Die Konnektivität wird als strikte Kausalkette verfolgt — Park-Anbindung, Netzwerkgeräte, Datenlogger, Komponenten — und der Watchdog unterscheidet die Arten, auf die eine Verbindung ausfallen kann, jede mit ihrem eigenen Ereignis:

Ein Alarm pro Grundursache. Jede Ebene löst nur dann Ereignisse aus, wenn alle darüberliegenden Ebenen gesund sind: Ein parkweiter Ausfall erzeugt genau ein Ereignis auf Parkebene und hält alles darunter stumm, ein ausgefallener Switch erzeugt ein Geräteereignis, und erst wenn Netzwerkpfad und Logger nachweislich in Ordnung sind, wird eine stumme Komponente zum Komponentenfehler. Alle Übergänge werden gegen Neustarts und kurze Aussetzer entprellt, und jedes Ereignis schließt sich bei Wiederherstellung automatisch und nennt dabei die Ausfalldauer.

Leistungs- und Produktionsprüfungen

Parallel dazu vergleicht der Watchdog die gemessene Leistung jeder Komponente in kurzen Auswertungsfenstern mit dem Modell der erwarteten Leistung. Ein Nullwert oder ein Defizit zählt nur dann als Indiz, wenn eine Umgebungsprüfung nachweist, dass die Bedingungen eine Produktion erwarten lassen — ausreichende anhaltende Einstrahlung, kein Schnee, Frost oder Nebel, kein aktiv greifendes Curtailment und ein gesunder Netzwerkpfad — sodass ein dunkler Wintermorgen niemals jemanden alarmieren kann.

Bevor ein Alarm geöffnet wird, wird der Befund einem Kreuzverhör mit unabhängigen Zeugen unterzogen: den untergeordneten Komponenten eine Hierarchieebene tiefer, dem eigenen Lebensdauer-Energiezähler und einem nächtlichen Energieabgleich zwischen über- und untergeordneten Komponenten. Das Ergebnis entscheidet, welche Art von Ereignis Sie erhalten:

• Produktionsausfall — die Komponente hat unter Bedingungen, unter denen sie produzieren sollte, tatsächlich aufgehört zu produzieren
• Messkonflikt — die Komponente produziert sehr wohl, aber ihr eigener Messwert ist falsch (ein zu untersuchender Datenfehler, der nie als verlorene Produktion gezählt wird)
• Keine Kommunikation — die Komponente meldet gar nichts mehr; die Produktion ist unbekannt und wird bewusst nicht als Verlust gezählt
• Minderleistung — die Komponente produziert, aber weit unter ihrer modellierten Erwartung (beurteilt sowohl live als auch in einem nächtlichen Ganztagesaudit)

Strings und Einstrahlungssensoren erhalten gestufte Untersuchungen statt sofortiger Urteile: Ein stummer String öffnet zunächst eine Untersuchung mit niedriger Priorität und wird erst bei physikalisch belastbarem Beweis als Ausfall oder Defekt bestätigt — zum Beispiel null Leistung unter bedecktem Himmel, während seine Nachbarn produzieren — während wiederkehrende Nullwerte, die dem Sonnenverlauf folgen, als Verschattung erkannt und erfasst werden, nicht als Defekt. Ein Sensor, dessen Einstrahlungskanal dunkel wird, während seine übrigen Kanäle aktiv bleiben, wird als Verschmutzung gemeldet (Kuppel reinigen) statt als Hardwaredefekt.

Vitalwerte der Wechselrichter

Die obigen Prüfungen fragen, ob ein Wechselrichter überhaupt noch produziert. Eine zweite Gruppe von Prüfungen fragt, ob ein produzierender Wechselrichter still auf einen Defekt zuläuft — indem sie die Signale liest, die der Agent ohnehin von jedem Wechselrichter erfasst, bisher aber nie zur Beurteilung herangezogen hat: Temperatur, Isolationswiderstand, Ströme und Spannungen je Phase sowie die DC-Seite (Spannung und Leistung).

Ein eigener Wartungsstrang. Diese Befunde treffen nie als Ausfall ein: Der Wechselrichter produziert, und noch geht nichts verloren. Sie öffnen als Wartungsbefunde, bewusst von den obigen Ausfallereignissen getrennt — die routinemäßigen Gesundheitsmeldungen eines produzierenden Wechselrichters können einen Wartungsbefund niemals schließen, und ein offener Wartungsbefund kann niemals einen echten Ausfallalarm blockieren. Sie verschieben auch keine Produktionszahl: Ein Wechselrichter mit einem Wartungsbefund zählt überall dort, wo die Plattform produzierende Komponenten zählt, weiterhin als produzierend — denn er produziert.

Jeder Befund ist ein eigenes Ereignis. Ein allgemeiner „Wartungsbedarf Wechselrichter“-Eintrag existiert nicht mehr — jeder Befund wird unter seinem eigenen, sprechenden Namen gemeldet (Erhöhte Temperatur, Nachlassende Isolation, Phasenunsymmetrie, Sinkender Wirkungsgrad), und jeder Wechselrichter trägt höchstens ein offenes Ereignis je Befund. Mehrere Befunde können deshalb am selben Gerät nebeneinander stehen, jeder mit eigener Begründung, eigener Historie und eigener Erholung, statt in einem einzigen Eintrag zu verschmelzen, der nur sagt: „hier ist etwas zu tun“.

Die Beobachtung ist sichtbar, das Urteil wartet. Ein frischer Verdacht verschwindet nicht mehr in der internen Buchführung des Agent. Sobald eine Prüfung genug Anhaltspunkte hat, um hinzusehen, öffnet sie ein Beobachtungsereignis niedriger Priorität — „Beobachtung: Erhöhte Temperatur“, „Beobachtung: Phasenunsymmetrie“ und so fort, mit demselben Symbol wie der bestätigte Befund, nur in hellerem Ton. In der Aktivitätsliste der Anlage sehen Sie damit genau, was das System beobachtet und seit wann. Was ein solches Ereignis bewusst nicht tut: den Gesundheitszustand einer Komponente verändern. Beobachtungen erscheinen nie in den Gesundheitsansichten — Analyse- und Produktionsseiten, Komponenten-Chips, Komponentenspalte der Stationen und deren Zählungen —, denn dort spricht die Plattform ein Urteil nur aus, wenn sie sicher ist. Eine Beobachtung ist eine Spur, kein Urteil.

Eine Kette vom ersten Verdacht bis zum Befund. Trifft der bestätigende Beleg ein, wird die Beobachtung geschlossen, und an ihrer Stelle öffnet der bestätigte Befund mit normaler Priorität, verknüpft mit der Beobachtung, aus der er hervorgegangen ist. Beide lesen sich als eine einzige Historie — ab diesem Tag beobachtet, an jenem Tag bestätigt —, und der Abschluss der Beobachtung meldet keine Behebung, denn nichts wurde behoben: Der Befund ist lediglich eine Stufe weitergerückt. Erst ab der Bestätigung erscheint er in den Gesundheitsansichten. Bleibt die Bestätigung aus, schließt die Beobachtung einfach wieder, sobald der Zustand verschwindet — behauptet wurde nie etwas.

Wartungsereignisse benennen die tatsächliche Wechselrichter-Komponente und tragen dieselbe Klartext-Begründung wie jedes andere Ereignis, mit den konkreten Zahlen dahinter — dem gemessenen Überschuss, dem Vergleich mit den Nachbargeräten, der Zahl der beobachteten Tage. Vorerst sind sie bewusst stumm: Sie erscheinen in der Ereignisliste der Anlage, liegen aber unterhalb jeder Benachrichtigungsschwelle, solange die neuen Prüfungen an Live-Flottendaten kalibriert werden. Wechselrichter-Ereignisse beschreibt, was jeden Befund öffnet, bestätigt und schließt.

Ursachenbelege an bestehenden Ereignissen

Zwei der neu gelesenen Signale erzeugen keine eigenen Ereignisse — sie stärken die bereits bestehenden:

AC-Seite oder DC-Seite? Öffnet der Watchdog einen Produktionsausfall eines Wechselrichters, liest er zusätzlich die DC-Spannung über genau jene Tageslichtfenster, in denen das Gerät nichts abgegeben hat. Ein dunkler DC-Zwischenkreis bedeutet, dass die Ursache auf der DC-Seite sitzt (Strings, DC-Schaltgeräte); ein spannungsführender bedeutet, dass der Generator intakt ist und der Fehler im Gerät selbst oder auf dessen AC-Seite liegt. Das Urteil — AC-seitig, DC-seitig oder unbestimmt — geht in die Begründung des Ausfallereignisses ein und entscheidet, welcher Serviceeinsatz überhaupt sinnvoll ist. Der Zeuge ist herstellerabhängig: Manche Geräte — Huawei etwa — melden nie einen dunklen Zwischenkreis; dort kann er die DC-Seite nur entlasten, nie beschuldigen.

Eine netzseitige Abregelung ist kein Defekt. Hält ein einzelner Wechselrichter während eines Minderleistungsfensters seine AC-Spannung beim 1,10-fachen seiner Nennspannung oder darüber, begrenzt er seine Abgabe absichtlich, gemäß der Volt-Watt-Regel der Netzanschlussvorgaben — er gehorcht dem Netz, statt zu versagen. Solche Fenster werden neutral gehalten, statt als Minderleistung gewertet zu werden, sodass sich ein straffer Netzanschluss nie zu einem falschen Defekt aufsummieren kann.

Wie schnell werden die Ereignisse erkannt?

Diese Detektoren beobachten nicht durchgehend. Sie laufen einmal pro Nacht — plus einmal kurz nach dem Start des Agent — und bauen ihre Belege bei jedem Durchlauf neu aus der gespeicherten Historie auf. Ein Zustand, der seit Wochen besteht, wird deshalb bei der ersten Auswertung gefunden, sobald seine Prüfstrecke scharfgeschaltet ist, und nicht erst Wochen später. Zeit kostet der Beleg selbst: Jede Prüfung verlangt eine Mindesthistorie und eine Persistenzstrecke, bevor sie überhaupt etwas sagt. Die erste Spalte unten nennt den Punkt, an dem die Beobachtung öffnet — niedrige Priorität, sichtbar in der Aktivitätsliste der Anlage, bewusst nicht in den Gesundheitsansichten. Die zweite nennt, was nötig ist, damit diese Beobachtung durch den offiziellen Befund ersetzt wird — und erst der erscheint in jenen Ansichten.

Eine frisch angebundene Anlage sieht ihre ersten Temperaturbeobachtungen daher nach rund drei Wochen und ihre ersten Effizienzbeobachtungen nach rund zwei Monaten, während DC-Zeuge und Netzentlastung ab dem ersten Tag arbeiten.

Zwei Grenzen sollte man kennen:

• Eine Vergleichsgruppe braucht mindestens sechs vergleichbare Wechselrichter. Alle diese Regeln sind vergleichsbezogen — jedes Gerät wird an seinen eigenen Geschwistern gemessen, nie an einer absoluten Schwelle, weil absolute Grenzen mit Generatorgröße und Hersteller skalieren. Die Folge ist bewusst in Kauf genommen: Verschlechtert sich eine ganze Vergleichsgruppe gleichzeitig auf dieselbe Weise, ist diese gemeinsame Drift mit dieser Methode nicht erkennbar.
• Die Abdeckung gilt je Wechselrichter und richtet sich nach den Daten. Eine Prüfung schaltet sich nur dort scharf, wo der Logger des Herstellers die Metrik tatsächlich liefert — kein Konfigurationsschalter aktiviert sie. Die Abdeckung unterscheidet sich daher von Anlage zu Anlage und von Hersteller zu Hersteller.

Ereignisse, die sich selbst erklären

Jedes Ereignis trägt eine Begründung in Klartext: was gemessen wurde, unter welchen Bedingungen, welche unabhängigen Belege es bestätigt oder widerlegt haben und was das Ereignis auflösen würde. Ereignisse schließen sich bei nachgewiesener Wiederherstellung automatisch, werden bei veränderter Beweislage an Ort und Stelle umklassifiziert (nie ein Schließen-und-Wiederöffnen-Flattern) und respektieren Ihre Entscheidungen — ein von Ihnen geschlossenes Ereignis bleibt geschlossen, bis der Fehler sich ein neues vollständig neu verdient hat. Ein einzelnes Sammelereignis „Komponenten ausgefallen“ auf Parkebene trägt den eigentlichen Betreiberalarm: Es öffnet sich, wenn mindestens ein Wechselrichter oder eine Combiner-Box über einen anhaltenden Zeitraum ausgefallen ist, listet die betroffenen Komponenten auf und benachrichtigt nur beim ersten Öffnen und bei der endgültigen Wiederherstellung.

Netzwerküberwachung

Der Data Scraper enthält einen integrierten Inspektor für das lokale Netzwerk, der parallel zur Datenerfassung läuft und das Vor-Ort-Netzwerk der Anlage kartiert. Er erkennt Geräte in den konfigurierten Netzwerkbereichen, indem er nach erreichbaren Hosts sucht, die Adresstabelle ausliest, Hersteller anhand von Hardware-Adressen identifiziert und Geräte nach ihrer Identität abfragt. Erkannte Geräte werden gegen eine umfangreiche Bibliothek bekannter Netzwerkgeräte-Profile klassifiziert, und ein Schritt zur KI-Geräteidentifikation hilft, Gerätefamilien zu erkennen, die einfache Regeln verpassen.

Sobald Geräte bekannt sind, fragt der Inspektor sie auf Erreichbarkeit und Gesundheit ab (Antwortzeit, Schnittstellen- und Ressourcenstatus) und meldet die Ergebnisse an die Plattform. Sie können einen Erkennungsscan auslösen oder stoppen, ein einzelnes Gerät erneut prüfen und das erkannte Netzwerk einsehen — siehe Inspektor für das lokale Netzwerk.

Proxy-Auditierung

Für Anlagen, die über den Mirox Browser-Proxy erreichbar sind, auditiert der Agent den menschlichen Zugriff auf lokale Geräteschnittstellen. Er gruppiert die Aktivität jeder Person in Sitzungen, schwärzt sensible Abfragedaten, bevor irgendetwas gespeichert wird, und kann eine KI-generierte Zusammenfassung dessen erstellen, was eine Sitzung getan hat. Dies fließt in den Zugriffs-Audit-Trail der Plattform ein — siehe Zugriffs-Audit-Log.

Leistungsmerkmale

Typische Leistung:

• Polling-Frequenzen: 1–300 Sekunden pro Adapter (konfigurierbar)
• Nebenläufige Adapter: 20+ gleichzeitig in Betrieb
• Durchsatz: 10.000+ Metriken pro Minute dauerhaft
• Latenz: Unter 100 ms von der Erfassung bis zum Datenbankeinfügen
• Ressourcennutzung: 5–15 % CPU, 100–500 MB Arbeitsspeicher auf Edge-Hardware

Die asynchrone Architektur gewährleistet hohe Nebenläufigkeit ohne Blockierung und ermöglicht eine effiziente Erfassung von vielen Quellen gleichzeitig.

Verwandte Funktionen

• Digital Twin — die physikbasierte Analyse-Engine, die die vom Data Scraper erfassten Metriken verarbeitet
• Mirox-Agent Überblick — wie sich der Data Scraper in den umfassenderen Edge-Agent einfügt
• Bereitstellungsoptionen — Abwägungen zwischen Vor-Ort- und Cloud-Bereitstellung des Agent
• Metrik-Erfassung — die vollständige standardisierte Metrik-Taxonomie
• Inspektor für das lokale Netzwerk — die Oberfläche zur Vor-Ort-Netzwerküberwachung
• Verlusterkennung — wie Curtailment und andere Verluste zugeordnet werden
• Ereignisse — wie die Park-Ereignisse des Watchdogs Sie erreichen