Digital Twin

The Digital Twin is the analysis engine inside the Mirox-Agent that turns your plant's measurements into component health, loss, configuration and settlement insights. It receives metrics from the Data Scraper, keeps an in-memory model of each plant's component hierarchy, runs physics-based models against historical data, and reports what it finds back to the platform.

The Digital Twin analyzes solar photovoltaic (PV) plants today. Wind and battery analysis are Planned — those plant types can already ingest data, but the Digital Twin does not yet analyze them.

Purpose and Role

The Digital Twin serves a focused purpose: understand each component's behavior and detect operational issues. It transforms raw measurements into actionable insights without persistent storage of its own.

Core Responsibilities:

• Receive metric updates from the Data Scraper
• Fetch historical data from the time-series database for analysis windows
• Build an in-memory model of the plant's component hierarchy from the IoT Cloud
• Discover and validate each string's configuration (orientation, panel count, inverter clipping, shadowing, performance)
• Monitor component health nightly, classify each component's state, and distinguish communication gaps from real outages
• Calculate energy losses with a confidence rating on every number
• Reconstruct every curtailment and calculate the compensable lost energy and its monetary value under the official legal settlement procedures
• Publish results and events back to the IoT Cloud platform for operators to see
• Flush memory after processing completes

This separation keeps the Digital Twin focused on analysis, while data collection and long-term storage live elsewhere.

Three Analysis Engines

The Digital Twin runs three distinct engines with different triggers and goals — keeping them apart explains why some insights appear immediately and others build up over several nights.

Architecture Overview

The Digital Twin operates as an asynchronous service processing metrics as they arrive:

Key Architectural Principles:

• Per-Plant: Each agent reasons about one plant as a component tree and evaluates per component and per level
• Stateless: No analysis results stored locally — data is processed in memory and flushed after completion
• Physics-Based: Industry-standard models (not machine learning) simulate expected production and compare it to reality
• Self-Calibrating: A feedback loop tunes the expected-production model to each component over a rolling window
• On-Demand and Scheduled: Configuration analysis and health monitoring both run automatically on their own schedules; configuration analysis can also be triggered on request

Core Components

Data Processing

The Digital Twin processes data on-demand without persistent storage:

Data Sources:

• Webhook: Receives real-time metric updates from Data Scraper
• Time-Series Database: Fetches historical data for analysis windows
• IoT Cloud: Loads park structure and component configuration

Processing Flow:

1. Webhook trigger or API request initiates processing
2. Load park structure from IoT Cloud into memory
3. Fetch required historical data from time-series database
4. Receive or use webhook-delivered real-time metrics
5. Perform analysis in memory
6. Publish results to IoT Cloud
7. Flush memory - no data persisted

Webhook Integration:

• Receives metric updates from Data Scraper via HTTP POST
• Metrics processed in memory during analysis execution
• No persistent metric storage within Digital Twin

Configuration Analysis

The Configuration Analysis engine discovers and validates what each string actually is, working from the bottom of the hierarchy upward (string, then combiner box, inverter, and feed-in meter). It runs automatically on its own schedule — once per week for each plant, and every night during a plant's first month after onboarding — plus once on startup for the previous day, and can additionally be triggered on demand for a chosen date range.

What it Detects (per string):

• Orientation — the panel azimuth, flagging deviation from the configured value
• Panel count — the actual number of working panels, surfacing missing or defective ones
• Inverter clipping — when DC power exceeds the inverter's AC capacity, with clipping duration and lost energy
• Shadowing — sunrise and sunset row-shadow periods and the resulting loss percentage
• Performance — measured-versus-simulated energy and a performance ratio for the string

Each result carries a reliability status, so an operator can tell whether a detection was reliable, came from too little data, hit values outside physical limits, or found no current at all (which can mark a string as unused).

Watchdog

The Watchdog engine monitors component health, separates real outages from communication gaps, and calculates energy losses. Unlike configuration analysis, it runs automatically every night for each plant.

Nightly Auto-Scheduling:

• Each plant is evaluated once per night at a stable time between 00:00 and 03:00 UTC, spread out so plants don't all run at once
• A plant joins the nightly schedule once enough of its strings have completed configuration analysis
• On its first run, the watchdog backfills history (up to roughly 180 days) so you get insights for the period before monitoring began
• The system tracks which days it has already processed and fills in any missing days on later nights — it self-heals without manual intervention

Health Evaluation:

• For each component, the watchdog simulates the production you should have seen and compares it to the measured value
• Components are classified into clear states: producing normally, degraded, overproducing, no data, stuck logger, inactive, and several inferred states for components whose data is missing but whose health can be deduced from neighbors
• A top-down pass infers the status of components with missing data from their parent: a missing inverter that the parent shows as healthy is correctly marked a communication issue, not an outage

Reference Irradiance Without a Sensor:

• The watchdog derives a measured-irradiance baseline from the best-producing strings, so accurate monitoring does not require an on-site irradiance sensor
• The existence of this reference baseline for a day is how the system knows that day has been processed

Self-Calibration (Performance Feedback Loop):

• A per-component correction factor is trained over a rolling window so the simulated expected production tracks each component's real behavior
• It learns only from healthy components and only on normal-weather days — anomalous days (heavy clouding, snow, faults) are skipped so bad data never poisons the model
• This is why expected-versus-actual comparisons sharpen over the first several days of a plant's life

Loss Detection with Confidence:

• Energy loss is calculated per interval as the shortfall of measured production below simulated production, never going negative
• Every loss figure is tagged HIGH, MEDIUM, or LOW confidence, and the buckets sum to the total — so you know how much to trust each number
• A flat (repeated) energy reading is examined: if production clearly continued through a brief gap it is treated as a communication outage and excluded from loss; if production stopped it is counted as a real outage
• Weather periods — snow, dew, fog, and grid or external shutdowns — are excluded for all components, so weather is never miscounted as a component fault

Curtailment Settlement

When the grid operator orders a plant down (negative redispatch under EnWG §13a / Redispatch 2.0), the operator is entitled to compensation for the Ausfallarbeit — the energy the plant would have produced but was not allowed to. The Curtailment Settlement engine reconstructs every curtailment, minute by minute, and calculates what the plant is owed — strictly following the official rules, with every result citing the legal document it was computed under.

Based on the Official Legal Framework:

• The applicable ruling is selected automatically per delivery month: BilAReM (the annex to BNetzA ruling BK6-23-241) for delivery months from July 2026, and its predecessor BK6-20-059 Anlage 1 for earlier months
• Grid-operator curtailment (redispatch) and marketer curtailment (market-driven reduction, marktbedingte Anpassung) are separated and settled independently — the first is claimed from the grid operator, the second concerns the direct marketer, and each segment of the park can be settled on its own
• The park's settlement case per the ruling — Duldungsfall (curtailment by toleration) or Aufforderungsfall (curtailment on instruction) — is applied and stated on every result

Three Settlement Methods in Parallel: which method is contractually binding differs from plant to plant, so the engine always computes and reports all three side by side:

• Spitzabrechnung ("Spitz") — the precise method using the park's own pyranometers: the nearest clean, uncurtailed reference day (Vergleichszeitraum) provides the plant's production-to-irradiance ratio, which is scaled to the irradiance actually measured during the curtailment
• Vereinfachte Spitzabrechnung ("Spitz light") — the simplified variant of the same method, using satellite irradiance converted to the module plane
• Pauschalverfahren — the flat-rate method per the BDEW guideline: the measured feed-in immediately before curtailment onset is frozen as the baseline, applied within the legally defined compensable time windows

From Energy to Money: the lost energy is valued at the official quarter-hourly Mischpreis (a blend of the ID1 price index and the imbalance price reBAP). Because official prices publish about two months after delivery, figures are marked as estimate until the official prices land, and the EEG §51 negative-price rules are computed alongside for every plant commissioning cohort.

Events Carry the Full Case File: everything relevant to a settlement is on the events themselves —

• Every curtailment episode appears live as a detected curtailment event within minutes: time window, limit level and source
• Each settled curtailment gets a settlement event carrying the time window and delivery month, the legal method and document citation, the settlement case, the chosen reference day (including the nearer candidate days that were rejected, with reasons), the lost energy per method in kWh, the monetary value with its estimate/official state, diagnostic flags, and a plain-language narrative explaining exactly how the figure came about
• A monthly settlement event states each month's value in EUR per method, and revision events record later official price corrections — history is never overwritten
• Events move from provisional to final as measurements and prices firm up, following the legally binding correction deadline

Operator Controls: authorized users can exclude a detected curtailment from settlement ("ignore") or record curtailments manually with stepped limit profiles — both reversible until the month's legal correction deadline.

Cloud Synchronization

The Digital Twin integrates with the IoT Cloud platform:

Park Structure Synchronization:

• Park Tree pulls component configuration from IoT Cloud
• Automatic updates when components are added or reconfigured
• Component discovery syncs back to cloud (inverters, strings, etc.)
• Configuration changes invalidate cached analysis results

Results Reporting:

• Analysis results pushed to IoT Cloud via REST API
• Event notifications for outages and degradation
• Performance metrics stored for historical tracking
• Status updates for component health

Operational Mode:

• Requires connectivity to IoT Cloud for normal operation
• Time-series database required for historical data analysis

Related Features

• Data Scraper — collects the plant metrics the Digital Twin analyzes
• Mirox-Agent Overview — how the Digital Twin and Data Scraper run together on the edge
• Digital Twin (feature) — the operator-facing view of these insights
• Loss Detection — how energy losses are detected and rated by confidence
• Efficiency Detection — string configuration and performance findings
• Component Evaluation — the component health states explained