Détection de pertes

Le système de surveillance par watchdog du jumeau numérique ne détecte pas seulement l'état des composants, il calcule aussi les pertes d'énergie précises de vos installations. La détection de pertes vous aide à comprendre la quantité d'énergie qu'un composant a perdue par rapport à la production attendue.

Concepts généraux

Principe de base de la détection de pertes

La détection de pertes compare l'énergie réellement produite avec l'énergie attendue sur la base des données météo et de la configuration du système :

• Énergie attendue : calculée par simulation à partir des conditions environnementales et des spécifications des composants
• Énergie mesurée : production réelle selon les compteurs d'énergie
• Perte : la différence lorsque l'énergie mesurée est inférieure à l'énergie attendue

Loss = max(0, Expected Energy - Measured Energy)

Quand les pertes sont-elles calculées ?

Le système ne calcule les pertes que sous certaines conditions, afin d'éviter les fausses alertes :

Les pertes SONT calculées pour :

• Les composants en sous-production significative : lorsque l'énergie mesurée est nettement inférieure à la simulation
• Pendant les périodes de panne détectées : durant les véritables défaillances de production
• Avec des données fiables : les mesures doivent être physiquement plausibles et cohérentes

Les pertes NE SONT PAS calculées pour :

• Les défaillances de communication : lorsque les data loggers n'envoient pas de données, mais que la production s'est poursuivie
• Les conditions météo défavorables : dans des conditions qui rendent les mesures peu fiables
• Les moments sans production attendue : lorsqu'aucune énergie n'est attendue en raison des conditions environnementales
• Les mesures non fiables : lorsque les mesures sont physiquement impossibles ou incohérentes

Classification des périodes

Le système analyse les séries temporelles d'énergie et classe chaque période :

Problème de collecte de données vs. perte réelle

Une source courante de confusion est un composant enfant (par exemple, un string) dont les données sont manquantes alors que son parent (l'onduleur) affiche clairement une production saine. Le système reconnaît ce schéma : si l'énergie mesurée de l'onduleur est cohérente avec une production normale de ses strings, l'absence de données du string est traitée comme un problème de collecte de données — un problème de logger ou de communication — et jamais comptabilisée comme une perte d'énergie.

Exemple : panne de communication vs. panne réelle

Scénario A : panne de communication (DATA_GAP)

Time:            08:00    [Gap]    12:00
Energy meter:    100 kWh    ???      180 kWh
                    │                  │
                    └──────────────────┘
                    Large jump: +80 kWh

Expected energy during gap: 100 kWh
Ratio: 80/100 = 80% ≥ 50% threshold

→ DATA_GAP: Component produced, only communication was interrupted
→ This period is EXCLUDED from loss calculation

Scénario B : panne réelle (POTENTIAL_OUTAGE)

Time:            08:00    [Gap]    12:00
Energy meter:    100 kWh    ???      105 kWh
                    │                  │
                    └──────────────────┘
                    Small jump: +5 kWh

Expected energy during gap: 100 kWh
Ratio: 5/100 = 5% < 50% threshold

→ POTENTIAL_OUTAGE: Likely a real outage
→ Losses are CALCULATED for this period

Niveaux de confiance

Chaque perte calculée reçoit un niveau de confiance indiquant à quel point le système est certain qu'il s'agit d'une perte réelle :

Conditions limites

Certaines conditions environnementales et météorologiques rendent l'analyse des pertes peu fiable. Ces périodes sont exclues pour TOUS les composants :

Conditions exclues :

Pourquoi des exclusions globales ?

Ces conditions affectent tous les composants simultanément et ne sont pas des problèmes spécifiques à un composant. Par exemple, lorsque de la neige est détectée, cette période est exclue du calcul des pertes pour tous les composants, même si certains composants affichent une faible production.

Détection de pertes pour les parcs solaires

Pour les parcs solaires, le système utilise une analyse multi-niveaux le long de la chaîne énergétique : depuis les strings individuels jusqu'au compteur d'injection réseau, en passant par les onduleurs.

Calcul hiérarchique des pertes

Les pertes sont calculées au niveau string et agrégées vers le haut :

String → GAK → Inverter → Feed-in Meter

Principes importants :

• Les pertes sont principalement calculées au niveau string
• Composants parents = Somme des composants enfants
• Si les données d'un string ne sont pas fiables, il est ignoré
• Le système valide que les pertes des strings ne dépassent pas les pertes physiquement possibles de l'onduleur

Exemple : cohérence hiérarchique

Inverter:
  Simulation: 10,000 Wh
  Measurement:  9,000 Wh
  Max. Loss: 1,000 Wh

String 1:                    String 2:
  Loss: 500 Wh               Loss: 500 Wh

Sum: 1,000 Wh = Inverter Max. Loss ✓

→ Consistent: String losses equal inverter loss

Conditions limites spécifiques aux parcs solaires

Pour les parcs solaires, des exclusions supplémentaires liées à la météo sont appliquées :

Day with morning snow:
Time   | Snow  | Loss Calculation
-------|-------|------------------
06:00  | 0 cm  | Calculate normally
07:00  | 2.5cm | EXCLUDED
08:00  | 3.1cm | EXCLUDED
09:00  | 1.8cm | EXCLUDED
10:00  | 0 cm  | Calculate normally

→ 07:00-09:00 excluded for ALL components
→ Even if string shows low production, no loss counted

Scénarios particuliers pour les parcs solaires

Panne d'onduleur avec trous de données des strings

Lorsqu'un onduleur tombe en panne, les data loggers des strings peuvent aussi tomber en panne. Dans ce cas :

1. Pendant la panne : TOUS les strings sont inclus (pas seulement les candidats)
2. Après la panne : seuls les strings affichant une performance médiocre en continu sont comptabilisés comme pertes
3. Avantage : évite que des pertes passent inaperçues à cause de défaillances de loggers

Corruption de compteur après des pannes

Il arrive que les compteurs de strings se bloquent après une panne d'onduleur :

String energy meter:
07:00  →  5000 Wh    (Normal)
07:45  →  5000 Wh    (Inverter failure, logger fails)
10:45  →  5000 Wh    (Inverter recovers, logger doesn't)
18:00  →  5000 Wh    (Meter stuck)

→ String appears as candidate (low daily production)
→ BUT: Only losses during 07:45-10:45 counted
→ After 10:45: No losses (meter corruption, not real loss)

Exemples de niveaux de confiance dans les parcs solaires

Perte de confiance HIGH :

String X:
- Daily simulation: 5,000 Wh
- Daily measurement: 4,000 Wh
- Sim_err: 0.80 (20% loss)
- Continuous data, no gaps
- Parent inverter healthy

→ Loss: 1,000 Wh with HIGH confidence
→ Clear case of underproduction

Perte de confiance MEDIUM :

String Y during inverter outage:
- Outage from 08:00 to 11:00
- Losses only counted during this period
- After outage: normal production

→ Loss: 800 Wh with MEDIUM confidence
→ Loss is limited to outage period

Perte de confiance LOW :

String Z:
- String reports 60% less than expected
- But: Inverter shows only 10% loss
- Data flow ratio inconsistent

→ Possible loss: 2,000 Wh with LOW confidence
→ Likely measurement problem, not real loss

Schémas de pertes courants dans les parcs solaires

Sous-production continue :

• Un string produit systématiquement 20 à 30 % de moins
• → Perte de confiance HIGH
• → Causes possibles : ombrage, salissures, modules défectueux

Pannes périodiques :

• Le string présente des périodes de panne récurrentes
• → Perte de confiance MEDIUM durant les pannes
• → Causes possibles : problème d'onduleur, problèmes réseau

Mesures incohérentes :

• Les pertes des strings ne correspondent pas aux pertes de l'onduleur
• → Confiance LOW
• → Cause probable : problème de mesure, pas une perte réelle

Interpréter les données de pertes

Comment évaluer les pertes

1. Vérifiez le niveau de confiance : concentrez-vous d'abord sur les pertes de confiance HIGH
2. Consultez l'état du composant : comparez avec les États des composants
3. Identifiez les schémas temporels : les pertes sont-elles continues ou périodiques ?
4. Validez la hiérarchie : pour les systèmes hiérarchiques (par exemple, les parcs solaires), vérifiez si les pertes sont cohérentes entre les différents niveaux

Attribution des pertes connexes

Tout déficit par rapport à la production attendue n'est pas une défaillance. L'agent edge suit séparément l'écrêtage — la production que vous avez été délibérément empêché de fournir — et l'attribue à la partie responsable :

• Écrêtage du commercialisateur : production réduite sur instruction de votre commercialisateur direct ou de votre partenaire de trading.
• Écrêtage réseau : production réduite par le gestionnaire de réseau (par exemple, la gestion de l'injection lors d'une congestion du réseau).

L'écrêtage est détecté lorsqu'une centrale est maintenue à son plafond de puissance active ou à proximité, et l'énergie non produite est enregistrée par minute au compte du commercialisateur ou du réseau plutôt que signalée comme une perte de composant. Cela vous permet de distinguer un string défectueux d'une centrale en parfait état de marche à laquelle on a simplement demandé de réduire sa puissance.

Fonctionnalités associées

• Jumeau numérique — le système de surveillance par watchdog qui détecte et calcule les pertes
• Évaluation des composants — comment l'état de chaque composant est classé
• Détection d'efficacité — analyse du performance ratio et de la configuration des strings
• Data Scraper — analyse en périphérie, incluant le suivi de l'écrêtage
• Architecture du jumeau numérique — implémentation technique