Digital Twin

The Digital Twin is the analysis engine inside the Mirox-Agent that turns your plant's measurements into component health, loss, and configuration 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
• 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.

Two Analysis Engines

The Digital Twin runs two 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 runs on request; health monitoring runs automatically every night

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 is triggered manually — once on startup for the previous day, and otherwise 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

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