Metrikerfassung

Mirox sammelt Leistungsdaten Ihrer Anlagen für erneuerbare Energien in einem einzigen, standardisierten Metrik-Vokabular — die Grundlage für jede Überwachungs-, Analyse-, Berichts- und Prognosefunktion der Plattform. Diese Seite ist der Referenzkatalog dafür, was gemessen wird und wie die Messungen organisiert sind.

Die vollständige Taxonomie umfasst 458 standardisierte Metriknamen in zwölf Familien: Anlagenproduktion (powerplant), Batteriespeicher, die Alarmanlage des Standorts, Wettereingaben, wetterbasierte Modelle sowie mehrere betriebliche Familien, die die Erfassung selbst beschreiben — Netzwerküberwachung, die Agenten, die Operator-Flotte, grundlegende Netzwerkerreichbarkeit und die Scraper-Quellen. Die folgenden Tabellen dokumentieren die Familien, die Sie am häufigsten visualisieren werden; die betrieblichen Familien werden in den Abschnitten Netzwerkmetriken und Agentenmetriken zusammengefasst.

Data-Scraper-Architektur

Im Kern der Metrikerfassung steht der Data Scraper, die Edge-Komponente, die Zeitreihendaten von Ihren Anlagen sammelt. Statt einer einzigen generischen Protokoll-Engine verwendet er einen eigenen Adapter pro Gerätefamilie (Datenlogger, Wechselrichter, Zähler, Batteriesysteme), der jeweils für die Schnittstelle des entsprechenden Herstellers entwickelt wurde. Der Data Scraper kann in zwei Bereitstellungsmodi betrieben werden:

Cloud-basierte Erfassung

Bei der Bereitstellung in der Cloud:

• Verbindet sich über sichere Internetverbindungen mit den Solarparks
• Aggregiert Daten von mehreren Standorten zentral
• Übernimmt Verbindungsverwaltung und Wiederholungslogik
• Optimiert die Bandbreitennutzung durch intelligentes Polling

Edge-basierte Erfassung

Bei der Bereitstellung am Edge (vor Ort):

• Schnittstelle direkt zur lokalen Ausrüstung für minimale Latenz
• Arbeitet mit lokaler Pufferung, um Internetausfälle abzufangen
• Führt vorläufige Datenvalidierung und -filterung durch
• Synchronisiert mit der Cloud, sobald eine Verbindung verfügbar ist

Die Dual-Mode-Architektur gewährleistet eine zuverlässige Datenerfassung unabhängig von den Konnektivitätsbedingungen des Standorts oder der Systemgröße.

Erfasste Metriken

Das Metrikerfassungssystem sammelt einen umfassenden Satz von Messungen, die vollständige Transparenz über die Leistung von Anlagen für erneuerbare Energien bieten. Die Metriken sind entlang dreier orthogonaler Achsen gruppiert:

• Standortmetriken beschreiben den physischen Standort selbst — seine Anlage, seinen Batteriespeicher, seine Alarmanlage und das umgebende Wetter.
• Netzwerkmetriken beschreiben die Konnektivität zwischen dem Standort und der Cloud.
• Agentenmetriken beschreiben die Datenerfassungsagenten selbst — die Scraper-Quellen und die unterstützenden Infrastrukturdienste, die auf dem IoT-Gerät laufen.

Standortmetriken

Standortmetriken sind die rohen Zeitreihenmessungen, die direkt von der an einem Standort für erneuerbare Energien installierten Ausrüstung erfasst werden. Sie sind nach Domäne in die Anlage (PV-Wechselrichter, Netzanschluss usw.), das Batteriespeichersystem (BESS), die Alarmanlage des Standorts und das Wetter (Vorhersage und modelliert) unterteilt.

Anlagenmetriken (Powerplant)

Netzmetriken

powerplant_grid_power ist die minutengenaue Interpolation von powerplant_power_grid, über alle Zähler summiert, und powerplant_grid_energy_total der daraus integrierte, boot-bewusste Energiezähler der Plattform — die eine monotone Erzeugungsreihe des Standorts, die die Analysen lesen (ein Park mit mehreren Zählern hat mehrere rohe powerplant_energy_grid_total-Zähler). Beide tragen ein boot_time-Label; den Zähler mit sum(increase(…)) lesen.

PV- und Batterie-Abgangszähler

Ein Park mit einer Batterie (oder einem weiteren Erzeuger) hinter demselben Netzanschlusspunkt misst jeden Abgang separat. Die Netzfamilie oben ist der Anschlusspunkt, parkweit summiert; der PV-Abgang veröffentlicht die Familie powerplant_pv_*, der Batterie-Abgang die Familie powerplant_battery_* — dieselben Größen mit derselben Vorzeichenkonvention (Erzeugung / Entladung positiv). Die beiden Batteriezähler sind nach dem benannt, was die Einheit getan hat: _energy_discharge_total ist die abgegebene, _energy_charge_total die aufgenommene Energie. Nicht zu verwechseln mit den battery_*-Familien unten, der Sicht des Batteriereglers auf seine Box-, Storage-, Modul- und Zellebene.

AC-Summen der Anlage

AC-Summen auf Anlagenebene, veröffentlicht von Loggern, die die Anlage als eine AC-Einheit melden (Legacy-Benennung, energy/power vor ac).

Wechselrichtermetriken

powerplant_inverter_power / powerplant_inverter_energy_total sind die über alle Wechselrichter summierten, minutengenauen Gegenstücke zum Netzpaar oben (eine Anlagenreihe mit boot_time-Label, nicht eine je Wechselrichter). powerplant_inverter_data_complete ist das minütliche Urteil über diese Summe: 1, wenn jeder erwartete Wechselrichter beigetragen hat, sonst 0, fehlend, wenn kein Urteil möglich war. powerplant_inverter_operating_state ist der Standard-Betriebszustand der Plattform, abgeleitet aus dem Statuscode des Herstellers (0 unbekannt, 1 Leerlauf, 2 produzierend, 3 begrenzt produzierend, 4 Selbstdrosselung, 5 per Befehl gestoppt, 6 durch Schutz gestoppt, 7 nicht erreichbar, 8 Fehler — so nummeriert, dass max den schlechtesten Zustand liefert), powerplant_inverter_derating_reason der herstellereigene Grundcode einer Drosselung.

Generatoranschlusskasten-Metriken (GAK)

String-Metriken

Windturbinen-Metriken

Eine Windturbine ist wie ein Wechselrichter eine flache Anlagenkomponente, identifiziert über das Label turbine_id (mit turbine_name und turbine_vendor). Die Werte sind die 10-Minuten-Mittel, die die Turbinensteuerung aufzeichnet. powerplant_turbine_blade_pitch_angle trägt ein blade-Label (A/B/C), powerplant_turbine_temperature ein sensor-Label (Getriebe, Generator, Transformator, Gondel, …). Die time_*-Reihen sind Sekunden je 10-Minuten-Intervall in jedem Zustand — gemessene Verfügbarkeit, nicht aus Lücken abgeleitet. Die Abregelungs- und Verlustreihen sind die gemessene Differenz zwischen möglicher und tatsächlicher Leistung, per Statuscode der Steuerung einer Partei zugeordnet (grid = Netzbetreiber, marketer = Direktvermarkter/Parkregler, environment = Schatten-/Fledermaus-/Eis-/Wetterstopps, command = manuelle oder Service-Stopps, fault = Turbinenalarm); ihre _energy_total-Zähler sind von der Plattform geführte Lebenszeitsummen.

Komponenten-Info-Reihen

Die Namen, die ein Betreiber den Komponenten gegeben hat, als eigene Reihen veröffentlicht, damit Dashboards die aktuellen Namen zeigen können, ohne dass die Telemetrie sie als Labels trägt (eine Label-Änderung würde eine Reihe aufspalten). Eine Reihe je Komponente, genau wie ihre Telemetrie geschlüsselt (inverter_id; gak_id; string_number, mit gak_id nur hinter einem Generatoranschlusskasten; id für einen Einspeisezähler; turbine_id) plus dem Namens-Label (inverter_name, gak_name, string_name, meter_name, turbine_name). Der Wert ist der Zeitpunkt der Veröffentlichung; die Reihe wird bei jeder Baumsynchronisation erneuert, eine Umbenennung erscheint also mit der nächsten Synchronisation. Diese Reihen nie plotten, summieren oder alarmieren — sie werden per Join an die Telemetrie angefügt, wie in Eigene Grafana-Dashboards erstellen gezeigt.

Steuerungsmetriken

Batterie-Sollwerte sind vorzeichenbehaftet (positiv = Entladung, negativ = Ladung): _external / _external_w ist die Vorgabe des Direktvermarkters, _local_w die manuelle Eingabe des Betreibers, _applied / _applied_w das, womit der Parkregler den Speicher tatsächlich ansteuert, nachdem er alle Vorgaben und Grenzen zu einer Zahl zusammengeführt hat. Grenzen sind positive Beträge: powerplant_max_power_import_by_grid ist die Grenze des Netzbetreibers für den Bezug der Anlage (100 = keine Reduzierung), die Paare battery_max_power_charge/discharge_by_grid sind die Grenzen des Netzbetreibers für den Speicher innerhalb einer größeren Anlage, eine Reihe je Richtung. Jedes Gerät veröffentlicht die Reihe, die es nativ angibt (Prozent oder Watt); die Plattform rechnet nie um.

Einstrahlungsmetriken

Umweltmetriken

Verlustmetriken

Berichtsmetriken

Digital-Twin-Metriken

Statusmetriken

Das tägliche Produktionsurteil der Plattform je Komponente: 1, wenn die Komponente normal produziert hat, sonst 0, mit dem detaillierten Zustand im status-Label. Nicht zu verwechseln mit powerplant_inverter_operating_state, das der Gerätestatus je Abfrage ist.

Konfigurierte Fakten

Einmal je parklokalem Tag von der Plattform aus der Anlagenkonfiguration veröffentlicht, nie gemessen: die Spitzenleistung jeder Komponente und des Parks, die Wechselrichtergrenze des Parks und die Komponentenanzahlen. Ausgeblendete Komponenten sind ausgeschlossen, ein nicht konfigurierter Wert schreibt keinen Messpunkt, sodass „nicht konfiguriert“ von „als null konfiguriert“ unterscheidbar bleibt. Wie jede Reihe lesen, z. B. last_over_time(powerplant_inverter_peak_power[1d]).

Veraltete Metriken

Nur für Dashboards beibehalten, die sie bereits verwenden — neue Dashboards sollten stattdessen powerplant_solar_radiation und powerplant_inverter_frequency verwenden.

Edge-Analytik-Metriken

Der Data Scraper berechnet eine Reihe von Analysen direkt an der Anlage und veröffentlicht sie als visualisierbare Zeitreihen neben den Rohmessungen. Dies sind die Zeitreihen hinter den Performance-Ratio-, Curtailment- und Abrechnungsfunktionen der Plattform. Die meisten Familien existieren einmal pro Einstrahlungsquelle — unten als <source> geschrieben, eine von pyranometer (Sensoren vor Ort), satellite (satellitenbasierte Einstrahlung für den Standort) oder weather (modellierte Einstrahlung aus meteorologischen Daten) — sodass jede Quelle ihre eigenen unabhängigen Zeitreihen behält und eine driftende Eingabe die anderen nie unbemerkt verfälschen kann.

Einstrahlung & modellierte Produktion

Die Einstrahlung in Modulebene, die jede Quelle sieht, und die daraus modellierte theoretische (unabgeregelte) Anlagenleistung. Ein Satz pro Quelle — insgesamt 13 Zeitreihen.

Performance-Ratio

Die tatsächliche Produktion im Vergleich zur modellierten Produktion — eine unabhängige PR-Spur pro Einstrahlungsquelle, auf Anlagenebene. Wie die Filter arbeiten, erfahren Sie unter Erwartete Leistung und Performance-Ratio.

Erwartete Leistung & Energie

Die PR-kalibrierte Erwartung — die modellierte Produktion, skaliert mit der realen Effizienz der Anlage. Dies ist die Baseline, an der der Komponentengesundheits-Watchdog die Live-Produktion misst.

Modell & Performance-Ratio pro Komponente

Das Pendant des anlagenweiten Modells auf Komponentenebene: theoretische Leistung und PR eines einzelnen Wechselrichters, Generatoranschlusskastens (GAK) oder Strings, unter Verwendung der eigenen Ausrichtung und Spitzenleistung der Komponente. Ausgegeben für die Quellen weather und pyranometer; die Zeitreihen tragen die Identitäts-Labels der Komponente. <component> ist eines von inverter, gak, string — insgesamt 12 Zeitreihen, plus die tägliche Abschlussmarkierung.

Live- & Prognose-Leistungsspuren

Echtzeit- und vorausschauende Produktionsreferenzen.

Curtailment

Entgangene Produktion, ihrer Ursache zugeordnet — <party> ist grid (ein Sollwert des Netzbetreibers begrenzt die Produktion) oder marketer (die Deckelung des Direktvermarkters begrenzt die Produktion). Jede Kombination wird als Momentanleistung und kumulierte Energie ausgegeben, in zwei Varianten: als abgerechnete Zeitreihe und als in Echtzeit berechnete live-Zeitreihe. Insgesamt 24 Zeitreihen.

Abrechnungsfamilien

Zeitreihen hinter Curtailment-Abrechnung und -Entschädigung. Die fixed-Familie (Pauschalverfahren) implementiert das quellenunabhängige Abrechnungsverfahren: Die Referenz ist die durchschnittlich gemessene Netzleistung der 15 Minuten vor Beginn des Curtailments, eingefroren für die gesamte Maßnahme — keine Einstrahlungseingabe nötig. Die Mischpreis-Familie bewertet Curtailment-Energie mit dem viertelstündlichen deutschen Markt-Mischpreis und liefert einen Erlöswert in EUR pro 15-Minuten-Intervall.

Wind-Abrechnungsfamilien

Onshore-Wind rechnet Abregelungen je Turbine ab und summiert sie zu einer Parkreihe: die Punkte je Turbine tragen ein turbine_id-Label, die Parksumme keines — mit turbine_id!~".+" auseinanderhalten, denn ein bloßes sum(...) über beide zählt doppelt. Drei Methoden teilen sich dieselbe Mathematik und dieselben Labels: nacelle (das eigene Anemometer der Turbine speist die zertifizierte Leistungskurve), windref (die Standardvariante — Windgeschwindigkeit einer Referenzturbine oder eines Wetterdienstes) und windfixed (pauschal: die letzte unbeschränkt gemessene Leistung, für die gesamte Maßnahme eingefroren). Die Marktprämien-Einspeisung ist die gemessene Netzeinspeisung mit jedem Negativpreis-Viertelstunde auf null gesetzt, eine Kopie je negative_price_rule. <party> ist grid oder marketer.

Batteriemetriken

Die Familie battery_* ist das herstellerunabhängige Metrik-Vokabular für jedes Batteriespeichersystem (BESS). Sie folgt einer strikten Komponentenhierarchie, bei der die Instanzidentifikation in Labels lebt, nicht im Metriknamen:

battery_environment_*       ambient sensors around the BESS
battery_pcs_*               grid-tied Power Conversion System in front of the box
battery_box_*               a BESS box / container — the DC battery
└── battery_storage_*       a cabinet / rack inside the box
    └── battery_module_*    a module inside the cabinet
        └── battery_cell_*  an individual cell inside the module

Die Batteriehierarchie (box → storage → module → cell) beschreibt die DC-Batterie selbst. Das PCS (battery_pcs_*) ist der netzgekoppelte AC↔DC-Wandler vor der Box — es besitzt die AC-Seite des BESS sowie eigene Wandler-Telemetrie und wird pro Gerät durch das Label pcs identifiziert. Die Modellierung als eigene Komponente erlaubt es, die Batterie und ihren Wandler als zwei unabhängige Geräte für denselben Container zu erfassen, ohne dass ihre Zeitreihen kollidieren.

Dies ist eine reine Erfassungs-Spezifikation — Adapter veröffentlichen Rohwerte exakt so, wie der Hersteller sie bereitstellt, ohne Aggregationen, Ableitungen, _min / _max / _mean-Modifikatoren oder Status- bzw. Health-Flags. Jegliche Interpretation, Zusammenfassung und Alarmierung sind nachgelagerte Aufgaben des Digital Twin.

Environment

Umgebungssensoren rund um das BESS — unterschieden durch das Label sensor.

PCS-Ebene

Das netzgekoppelte Power Conversion System — der AC↔DC-Wandler vor der Batteriebox. Es besitzt die AC-Seite des BESS (die die DC-Batterie nie misst), dazu die eigene DC-Bus-Messung, den weitergereichten Batteriezustand und wandlerseitige Telemetrie. Ein PCS ist ein eigenständiges Gerät, identifiziert durch das Label pcs; phase unterscheidet phasenbezogene AC-Größen. Vorzeichenkonvention: positiv = Laden (Netz → Batterie); die Richtung wird aus den richtungsgetrennten Energiezählern abgeleitet, nie aus einem Status-Bit.

DC-Bus

Die eigene Sicht des Wandlers auf den DC-Zwischenkreis — der maßgebliche DC-Zustand der Batterie bleibt auf Box-Ebene.

AC-Seite

Sollwerte

Nur-Lese-Sicht auf die aktiven Dispatch-Vorgaben.

Energiezähler

Veröffentlicht exakt so, wie die Lebensdauerzähler des Geräts sie melden — getrennte richtungsbezogene Zähler, sodass keine Vorzeichenentscheidung nötig ist.

Weitergereichter Batteriezustand & Wandlergrenzen

Das PCS reicht eine Zusammenfassung des Batteriemanagements weiter und meldet seine eigenen dynamischen Betriebsgrenzen. Wo das Batteriemanagementsystem direkt erfasst wird, ist battery_box_soc maßgeblich und der weitergereichte Wert redundant; an einem Standort, an dem nur das PCS erfasst wird, ist er der einzige verfügbare Ladezustand.

Box-Ebene

Die oberste Ebene der Batterieseite — eine BESS-Box / ein Container. Erforderliches Label: box. Optionale Labels: inverter, phase. AC-seitige Metriken sind nur vorhanden, wenn die AC↔DC-Wandlung physisch auf Box-Ebene angesiedelt ist.

AC-seitiger Energiefluss

DC-seitige Schnittstelle

Chemie & Zustand

Storage-Ebene

Ein Schrank / Rack innerhalb einer Box. Erforderliche Labels: box, storage. AC-Metriken sind auf dieser Ebene selten — sie sind nur vorhanden, wenn die AC↔DC-Wandlung physisch auf Storage-Ebene angesiedelt ist.

AC-seitiger Energiefluss

Dasselbe AC-Vokabular wie auf Box-Ebene, ohne Phasen- oder Sollwert-Varianten.

DC-seitige Schnittstelle

Chemie & Zustand

Modul-Ebene

Ein Modul innerhalb eines Schranks — die kleinste Einheit mit eigenem BMS-Chip. Erforderliche Labels: box, storage, module. AC-Metriken sind hier praktisch nie vorhanden.

DC-seitige Schnittstelle

Chemie & Zustand

Zell-Ebene

Die kleinste physische Einheit. Zellen sind innerhalb eines Moduls in Reihe geschaltet und teilen sich den Modulstrom, sodass Strom und Leistung pro Zelle nicht aussagekräftig sind. Erforderliche Labels: box, storage, module, cell.

Wettervorhersage-Metriken

Tägliche Wettermetriken

15-Minuten-Wettermetriken

Wetterberechnungs-Metriken

Wettermodell-Metriken

Wettermodell-Leistungsmetriken

Clearsky-Modell-Leistungsmetriken

Alarmanlagen-Metriken

Die Familie alarm_* ist die Alarmmeldung des Standorts selbst. Nichts darin wird gemessen: Jeder Wert ist die Stellung eines Relaiskontakts, gelesen über die digitalen Eingänge einer Steuerung — die Relaisausgänge einer Einbruchmeldezentrale sowie die Überwachungskontakte des Kommunikationsschranks, über den die Zentrale verdrahtet ist.

Jede Serie ist ein 0/1-Messwert, normalisiert so, dass 1 immer „der Zustand liegt vor“ bedeutet (Tür offen, Alarm ausgelöst, USV im Batteriebetrieb, Automat gefallen) und 0 „normal“, unabhängig von der Polarität des Kontakts. Ein fehlender Wert ist nie eine 0: Ein Signal, das das Gerät in diesem Zyklus nicht geliefert hat, wird gar nicht veröffentlicht, und ein vom Betreiber als nicht verdrahtet erklärter Kontakt wird zurückgehalten, statt dauerhaft im Alarm zu stehen. Die Instanzkennung liegt im Label alarm — die Alarmanlage, zu der die Signale gehören — nie im Metriknamen.

Jedes Signal außer alarm_door_open öffnet außerdem für die Dauer seines Anliegens ein Parkereignis gleichen Namens; eine offene Tür ist Routine und bleibt reine Serie. Die Seite, die diese Serien speist, beschreibt Alarmanlage.

Netzwerkmetriken

Netzwerkmetriken beschreiben die Konnektivität zwischen dem IoT-Gerät und der Cloud, unabhängig von einem bestimmten Scraper oder Dienst.

Netzwerküberwachungs-Metriken

Die eigenen aktiven Prüfungen des Agenten (ICMP, TCP, HTTP) gegen die Geräte im Anlagennetz. Reihen je Gerät tragen device_ip, device_name, device_type und device_vendor; TCP-Prüfungen ergänzen den Port, HTTP-Prüfungen den Endpunkt. netmon_park_network_up ist eine zusammenfassende Reihe je Anlage.

SNMP-Metriken

Von SNMP-fähigen Geräten im Anlagennetz gelesen (Switches, Router, Gateways). Gerätereihen tragen dieselben Geräte-Labels wie oben; Schnittstellenreihen ergänzen if_index, if_name und if_type.

Agentenmetriken

Agentenmetriken beschreiben die Datenerfassungsagenten selbst — sowohl den Zustand einzelner Scraper-Adapter pro Quelle als auch die allgemeine Gesundheit und den Datenverkehr der Agenten und der unterstützenden Konnektivität. Diese Metriken ermöglichen es Ihren Dashboards, Datenlücken mit Adapter- oder Konnektivitätsausfällen statt mit der gemessenen Ausrüstung zu korrelieren.

Scraper-Quellenmetriken

Der Data Scraper gibt einen Satz dieser Metriken pro aktiver Adapter-Quelle aus. Die Zeitreihen werden durch die Labels source, source_num und name unterschieden, sodass Datenlücken direkt mit der Adapter-Gesundheit statt mit der gemessenen Ausrüstung korreliert werden können.

• scraper_health_state: Aktueller Adapter-Zustand, codiert als Ganzzahl: 0 = Initialisierung, 1 = gesund, 2 = ungesund, 3 = wird neu verbunden, 4 = eingefroren (der Logger liefert veraltete/feststeckende Werte), 5 = pausiert.
• scraper_cycles_total: Anzahl der Abrufzyklen, die der Adapter seit Prozessstart ausgeführt hat (wird beim Neustart zurückgesetzt).
• scraper_errors_total: Anzahl der Abrufzyklen, die seit Prozessstart mit einer Ausnahme endeten (wird beim Neustart zurückgesetzt).
• scraper_last_success_timestamp: Unix-Epochensekunden des letzten erfolgreichen Abrufzyklus. Wird erst nach dem ersten Erfolg ausgegeben.

Agentendienst-Metriken

Diese Metriken verfolgen die Gesundheit und Netzwerknutzung der einzelnen Agentendienste (Data Scraper, Digital Twin und unterstützende Dienste), die auf einem Gerät laufen, sodass Sie erkennen können, ob eine Datenlücke an der Ausrüstung oder am Agenten selbst liegt.

Netzwerkverkehr

Agentengesundheit

Organisations-VPN

Konnektivität und Datenverkehr für die organisationsweite VPN-Verbindung zwischen der Anlage und der Cloud.

Direktes VPN

Konnektivität und Datenverkehr für jeden direkten (anlagenspezifischen) VPN-Tunnel. Die Zeitreihen tragen ein Label vpn_name, sodass jeder Tunnel einzeln identifiziert wird.

SaaS-VPN

Konnektivität und Datenverkehr für den integrierten Agent-zu-Cloud-Tunnel, der den Fernzugriffs-Datenverkehr der Plattform zur Anlage transportiert.

VPN-Server

Wenn der Agent selbst als VPN-Server für eingehende Verbindungen agiert, melden diese Metriken den Serverzustand und jeden verbundenen Peer. Die Zeitreihen pro Peer tragen die Labels interface, peer_uid und peer_kind, sodass Dashboards Benutzerverbindungen und Standortkopplungen unterscheiden können.

• agent_vpn_server_peer_last_handshake: Unix-Epochensekunden des letzten abgeschlossenen Handshakes des Peers; 0 bedeutet, dass der Peer nie einen abgeschlossen hat. Für OpenVPN-Peers, die keinen Zeitstempel pro Handshake bereitstellen, wird der Zeitpunkt des Verbindungsaufbaus unter derselben Metrik veröffentlicht, sodass eine Abfrage beide Protokolle abdeckt.

Operator-Metriken

Die Operator-Flotte sendet Infrastrukturmetriken für die VPN-Tunnelüberwachung und die Operator-Gesundheit, sodass Sie den Zustand der cloudseitigen Konnektivität sehen können, die Ihre Anlagen mit der Plattform verbindet.

VPN-Tunnel-Metriken

• operator_vpn_connected: 1, wenn der VPN-Tunnel einen aktuellen Handshake hat (innerhalb der letzten 3 Minuten), sonst 0
• operator_vpn_rx_bytes: Gesamtzahl der über den VPN-Tunnel empfangenen Bytes (Zähler)
• operator_vpn_tx_bytes: Gesamtzahl der über den VPN-Tunnel übertragenen Bytes (Zähler)

Operator-Gesundheitsmetriken

• operator_health: 1, wenn der Operator eine aktive Cloud-Verbindung hat, 0 im Timeout-Zustand
• operator_uptime_seconds: Sekunden seit dem Start des Operator-Prozesses
• operator_cloud_response_age_seconds: Sekunden seit der letzten erfolgreichen Cloud-API-Antwort
• operator_cloud_liveness_age_seconds: Sekunden, seit der Cloud-Prozess zuletzt als lebendig bestätigt wurde (Health-Endpunkt) — bleibt auch aktuell, während die Haupt-API Fehler liefert, und ist daher das Failsafe-Kriterium

Erfassungsprozess

Der Datenerfassungsprozess folgt einem strukturierten Workflow:

1. Erkennung: Das System identifiziert alle zu überwachenden Komponenten anhand der Park-Konfiguration
2. Planung: Erfassungspläne werden auf Basis von Metrikwichtigkeit und Variabilität optimiert
3. Abruf: Der Data Scraper verbindet sich mit den Geräten und sammelt Rohmessungen
4. Validierung: Die erfassten Daten werden auf Genauigkeit und Bereichskonformität geprüft
5. Anreicherung: Kontextinformationen werden hinzugefügt (Zeitstempel, Komponentenkennungen usw.)
6. Übertragung: Die Daten werden sicher an die Zeitreihendatenbank übertragen
7. Verifizierung: Das System bestätigt die erfolgreiche Speicherung und Verfügbarkeit

Integrationspunkte

Das Metrikerfassungssystem integriert sich mit anderen Plattformkomponenten:

• Überwachungs-Dashboard: Bietet Echtzeit-Datenvisualisierung
• Ereigniserkennung: Liefert Daten zur Identifikation von Anomalien und Problemen
• Berichts-Engine: Stellt Messungen für Leistungsberichte bereit
• Analysesystem: Speist Daten in erweiterte Leistungsberechnungen ein
• Prognosemodul: Liefert historische Daten für Vorhersagemodelle

Datensicherheit

Alle erfassten Metriken werden durch mehrere Sicherheitsmaßnahmen geschützt:

• Verschlüsselung: Die Daten werden sowohl bei der Übertragung als auch im Ruhezustand verschlüsselt
• Zugriffskontrolle: Metriken unterliegen demselben Berechtigungsmodell wie andere Ressourcen
• Auditierung: Jeder Zugriff auf Metrikdaten wird zu Compliance-Zwecken protokolliert
• Anonymisierung: Aggregierte Daten, die für Benchmarking verwendet werden, werden anonymisiert

Erweiterbarkeit

Das Metrikerfassungssystem ist auf Erweiterbarkeit ausgelegt:

• Neue Gerätefamilien: Wir entwickeln auf Anfrage einen eigenen Adapter für jede Gerätefamilie — wenn Ihre Anlage einen Logger, Wechselrichter, Zähler oder ein Batteriesystem verwendet, das wir noch nicht unterstützen, kann es ohne eine generische Universallösung hinzugefügt werden.
• Benutzerdefinierte Metriken: Unterstützung für standort- oder gerätespezifische Messungen.
• Externe Datenquellen: Wetter- und Referenz-Einstrahlungsreihen werden zusammen mit Ihren Anlagendaten eingebunden, um Analyse und Prognose zu ermöglichen.

Verwandte Funktionen

• Data Scraper — der Edge-Agent, der diese Metriken mit einem eigenen Adapter pro Gerätefamilie sammelt
• Digital Twin — wandelt die Rohmetriken in simulierte Produktion, Performance Ratio und Verlustbefunde um
• Metrics Export API — fragen Sie diese Metriken ab und laden Sie sie für Ihre eigene Verwendung herunter
• MiroxQL — das Abfrageformat für programmatischen und Rohdatenzugriff auf Ihre erfassten Metriken
• Echtzeit-Überwachung — Live-Dashboards, die auf den erfassten Metriken aufbauen