Jumeau numérique

Le jumeau numérique est le moteur d'analyse au cœur du Mirox-Agent qui transforme les mesures de votre installation en informations sur la santé des composants, les pertes et la configuration. Il reçoit les métriques du Data Scraper, conserve en mémoire un modèle de la hiérarchie de composants de chaque installation, exécute des modèles fondés sur la physique sur des données historiques et restitue ses conclusions à la plateforme.

Le jumeau numérique analyse aujourd'hui les installations photovoltaïques (PV) solaires. L'analyse de l'éolien et des batteries est Planifiée — ces types d'installation peuvent déjà ingérer des données, mais le jumeau numérique ne les analyse pas encore.

Objectif et rôle

Le jumeau numérique poursuit un objectif ciblé : comprendre le comportement de chaque composant et détecter les problèmes opérationnels. Il transforme les mesures brutes en informations exploitables sans stockage persistant propre.

Responsabilités principales :

Recevoir les mises à jour de métriques du Data Scraper
Récupérer les données historiques de la base de données de séries temporelles pour les fenêtres d'analyse
Construire en mémoire un modèle de la hiérarchie de composants de l'installation à partir de l'IoT Cloud
Découvrir et valider la configuration de chaque string (orientation, nombre de panneaux, écrêtage de l'onduleur, ombrage, performance)
Surveiller la santé des composants chaque nuit, classer l'état de chaque composant et distinguer les coupures de communication des véritables pannes
Calculer les pertes d'énergie avec un indice de confiance sur chaque valeur
Publier les résultats et les événements vers la plateforme IoT Cloud pour les exploitants
Vider la mémoire une fois le traitement terminé

Cette séparation maintient le jumeau numérique concentré sur l'analyse, tandis que la collecte des données et le stockage à long terme résident ailleurs.

Deux moteurs d'analyse

Le jumeau numérique exécute deux moteurs distincts, avec des déclencheurs et des objectifs différents — leur distinction explique pourquoi certaines informations apparaissent immédiatement tandis que d'autres se construisent sur plusieurs nuits.

Moteur	Ce qu'il détermine	Quand il s'exécute
Analyse de configuration	L'orientation détectée de chaque string, le nombre de panneaux, l'écrêtage de l'onduleur, l'ombrage et la performance	Manuel — au démarrage (pour la veille) et à la demande
Watchdog	Les états de santé des composants, les véritables pannes vs. les coupures de communication, et les pertes d'énergie	Automatique — chaque nuit par installation, avec rattrapage

Pourquoi les informations prennent du temps

Une installation fraîchement intégrée nécessite plusieurs nuits d'exécutions du watchdog avant que son modèle de production attendue ne se calibre sur le comportement réel de chaque composant. Les premières valeurs se stabilisent au cours des premiers jours.

Aperçu de l'architecture

Le jumeau numérique fonctionne comme un service asynchrone qui traite les métriques au fur et à mesure de leur arrivée :

Principes architecturaux clés :

Par installation : chaque agent raisonne sur une installation comme un arbre de composants et évalue par composant et par niveau
Sans état : aucun résultat d'analyse n'est stocké localement — les données sont traitées en mémoire et vidées une fois l'opération terminée
Fondé sur la physique : des modèles standards du secteur (pas de machine learning) simulent la production attendue et la comparent à la réalité
Auto-calibrant : une boucle de rétroaction ajuste le modèle de production attendue à chaque composant sur une fenêtre glissante
À la demande et planifié : l'analyse de configuration s'exécute sur demande ; la surveillance de la santé s'exécute automatiquement chaque nuit

Composants principaux

Traitement des données

Le jumeau numérique traite les données à la demande, sans stockage persistant :

Sources de données :

Webhook : reçoit les mises à jour de métriques en temps réel du Data Scraper
Base de données de séries temporelles : récupère les données historiques pour les fenêtres d'analyse
IoT Cloud : charge la structure du parc et la configuration des composants

Flux de traitement :

Un déclencheur webhook ou une requête API lance le traitement
Charger la structure du parc depuis l'IoT Cloud en mémoire
Récupérer les données historiques requises depuis la base de données de séries temporelles
Recevoir ou utiliser les métriques en temps réel transmises par le webhook
Effectuer l'analyse en mémoire
Publier les résultats vers l'IoT Cloud
Vider la mémoire — aucune donnée persistée

Intégration du webhook :

Reçoit les mises à jour de métriques du Data Scraper via HTTP POST
Métriques traitées en mémoire pendant l'exécution de l'analyse
Aucun stockage persistant de métriques au sein du jumeau numérique

Analyse de configuration

Le moteur d'analyse de configuration découvre et valide ce qu'est réellement chaque string, en remontant la hiérarchie depuis le bas (string, puis boîte de jonction, onduleur et compteur d'injection). Il est déclenché manuellement — une fois au démarrage pour la veille, et sinon à la demande pour une plage de dates choisie.

Ce qu'il détecte (par string) :

Orientation — l'azimut des panneaux, signalant tout écart par rapport à la valeur configurée
Nombre de panneaux — le nombre réel de panneaux en fonctionnement, faisant ressortir ceux manquants ou défectueux
Écrêtage de l'onduleur — lorsque la puissance DC dépasse la capacité AC de l'onduleur, avec la durée d'écrêtage et l'énergie perdue
Ombrage — les périodes d'ombre entre rangées au lever et au coucher du soleil et le pourcentage de perte qui en résulte
Performance — l'énergie mesurée versus simulée et un ratio de performance pour le string

Chaque résultat est assorti d'un statut de fiabilité, afin qu'un exploitant puisse savoir si une détection était fiable, provenait de données trop rares, atteignait des valeurs hors des limites physiques, ou ne trouvait aucun courant du tout (ce qui peut marquer un string comme inutilisé).

Solaire uniquement aujourd'hui

Les analyses de configuration ci-dessus s'appliquent aux strings PV solaires. La détection de l'inclinaison des panneaux est mentionnée mais pas encore implémentée, et il n'existe aucune analyse de configuration pour les installations éoliennes ou de batteries.

Modèles physiques standards du secteur

Le jumeau numérique utilise des modèles physiques évalués par des pairs plutôt que du machine learning — par exemple, un modèle d'irradiance par ciel clair et un modèle de panneau à diode unique pour le solaire. La production attendue est calculée à partir de la physique et de la géométrie du site, puis comparée à ce que l'installation a réellement produit.

Watchdog

Le moteur Watchdog surveille la santé des composants, distingue les véritables pannes des coupures de communication et calcule les pertes d'énergie. Contrairement à l'analyse de configuration, il s'exécute automatiquement chaque nuit pour chaque installation.

Planification automatique nocturne :

Chaque installation est évaluée une fois par nuit à un horaire stable entre 00:00 et 03:00 UTC, réparti dans le temps afin que toutes les installations ne s'exécutent pas en même temps
Une installation rejoint la planification nocturne dès qu'un nombre suffisant de ses strings a terminé l'analyse de configuration
Lors de sa première exécution, le watchdog rattrape l'historique (jusqu'à environ 180 jours) afin que vous obteniez des informations pour la période antérieure au début de la surveillance
Le système suit les jours déjà traités et comble les jours manquants lors des nuits suivantes — il s'auto-répare sans intervention manuelle

Évaluation de la santé :

Pour chaque composant, le watchdog simule la production que vous auriez dû observer et la compare à la valeur mesurée
Les composants sont classés dans des états clairs : production normale, dégradé, surproduction, aucune donnée, logger bloqué, inactif, ainsi que plusieurs états inférés pour les composants dont les données sont manquantes mais dont la santé peut être déduite des voisins
Une passe descendante infère le statut des composants aux données manquantes à partir de leur parent : un onduleur manquant que le parent indique comme sain est correctement marqué comme un problème de communication, pas une panne

Irradiance de référence sans capteur :

Le watchdog dérive une référence d'irradiance mesurée à partir des strings les plus productifs, de sorte qu'une surveillance précise ne nécessite pas de capteur d'irradiance sur site
L'existence de cette référence pour un jour donné est ce qui permet au système de savoir que ce jour a été traité

Auto-calibration (boucle de rétroaction de performance) :

Un facteur de correction par composant est entraîné sur une fenêtre glissante afin que la production attendue simulée suive le comportement réel de chaque composant
Il n'apprend que des composants sains et uniquement les jours à météo normale — les jours anormaux (forte nébulosité, neige, défauts) sont ignorés afin que de mauvaises données n'altèrent jamais le modèle
C'est pourquoi les comparaisons attendu-versus-réel s'affinent au cours des premiers jours de vie d'une installation

Détection des pertes avec confiance :

La perte d'énergie est calculée par intervalle comme le déficit de la production mesurée sous la production simulée, sans jamais devenir négative
Chaque chiffre de perte est étiqueté avec une confiance HIGH, MEDIUM ou LOW, et les catégories totalisent l'ensemble — vous savez ainsi à quel point faire confiance à chaque valeur
Une lecture d'énergie plate (répétée) est examinée : si la production s'est clairement poursuivie pendant une brève coupure, elle est traitée comme une coupure de communication et exclue de la perte ; si la production s'est arrêtée, elle est comptée comme une véritable panne
Les périodes météorologiques — neige, rosée, brouillard, et arrêts réseau ou externes — sont exclues pour tous les composants, de sorte que la météo n'est jamais comptabilisée à tort comme un défaut de composant

Les coupures de communication ne sont pas des pertes

Lorsqu'un composant parent est sain mais que les données d'un enfant sont manquantes, le watchdog signale un problème de collecte de données, et non une perte de production. Cela évite qu'un logger temporairement hors ligne soit confondu avec de l'énergie perdue.

Synchronisation avec le cloud

Le jumeau numérique s'intègre à la plateforme IoT Cloud :

Synchronisation de la structure du parc :

Le Park Tree récupère la configuration des composants depuis l'IoT Cloud
Mises à jour automatiques lorsque des composants sont ajoutés ou reconfigurés
La découverte de composants se synchronise vers le cloud (onduleurs, strings, etc.)
Les modifications de configuration invalident les résultats d'analyse en cache

Restitution des résultats :

Résultats d'analyse poussés vers l'IoT Cloud via une API REST
Notifications d'événements pour les pannes et les dégradations
Métriques de performance stockées pour le suivi historique
Mises à jour de statut pour la santé des composants

Mode opérationnel :

Nécessite une connectivité à l'IoT Cloud pour un fonctionnement normal
Base de données de séries temporelles requise pour l'analyse des données historiques

Fonctionnalités associées

Data Scraper — collecte les métriques de l'installation que le jumeau numérique analyse
Aperçu du Mirox-Agent — comment le jumeau numérique et le Data Scraper s'exécutent ensemble sur l'edge
Jumeau numérique (fonctionnalité) — la vue de ces informations côté exploitant
Détection des pertes — comment les pertes d'énergie sont détectées et notées par niveau de confiance
Détection d'efficacité — les conclusions sur la configuration et la performance des strings
Évaluation des composants — les états de santé des composants expliqués