Data Scraper

Le Data Scraper est le moteur de collecte de données au cœur du Mirox-Agent : il récupère activement les informations en temps réel de tous les équipements supervisés de votre installation. Il se connecte à vos loggers, onduleurs, compteurs et systèmes de batteries grâce à une bibliothèque d'adaptateurs spécifiques aux constructeurs, normalise l'ensemble dans un vocabulaire de métriques cohérent, puis transmet le résultat au reste de la plateforme — tout en exécutant un ensemble croissant d'analyses edge (performance ratio, suivi de l'écrêtement, références ciel clair, prévisions et supervision réseau) ainsi qu'un watchdog de santé des composants en continu, directement sur l'installation.

Objectif et rôle

Le Data Scraper poursuit un objectif unique et bien ciblé : collecter activement les mesures brutes des équipements et les transmettre pour traitement. Il fait office de passerelle entre la diversité des équipements des constructeurs et la plateforme Mirox unifiée, en traduisant des formats de données propriétaires en métriques standardisées.

Responsabilités principales :

• Se connecter aux data loggers et appareils de supervision via des adaptateurs spécifiques aux constructeurs
• Récupérer les mesures brutes selon des cadences configurables
• Transformer les données propres à chaque constructeur en un format de métrique standardisé
• Découvrir et suivre automatiquement les composants de l'installation
• Surveiller l'activité et l'état opérationnel des composants
• Surveiller en continu la santé et l'état de connexion des composants, et générer des événements de parc pour les pannes, les conflits de mesure et les problèmes de connexion
• Exécuter des analyses edge (puissance attendue, performance ratio, écrêtement, ciel clair et prévisions)
• Inspecter le réseau local de l'installation et auditer les accès aux appareils
• Transmettre les métriques à la base de données temporelle et au service Digital Twin
• Remonter l'état de santé et le statut opérationnel des composants à l'IoT Cloud

Cette séparation des responsabilités maintient le Data Scraper léger, ciblé et déployable de manière indépendante.

Vue d'ensemble de l'architecture

Le Data Scraper fonctionne comme un service asynchrone, piloté par événements, où plusieurs tâches de collecte de données s'exécutent simultanément :

Principes architecturaux clés :

• Sans base de données propre : aucun état d'analyse ne survit aux redémarrages ; les données non livrées sont mises en tampon sur le disque local jusqu'à leur envoi
• Basé sur des adaptateurs : un adaptateur dédié, spécifique au constructeur, parle le protocole de chaque appareil
• Auto-réparateur : récupération automatique des erreurs avec backoff exponentiel
• Concurrent : chaque source de données est collectée indépendamment
• Déployé en edge : s'exécute sur l'installation ou à proximité, au plus près des équipements qu'il lit

Le système d'adaptateurs

Concept

Un adaptateur est un module connecteur spécifique à un constructeur qui sait communiquer avec une famille d'appareils particulière. Chaque adaptateur est développé à la main et conçu par rétro-ingénierie de l'interface web, API ou base de données propre à l'appareil — il n'existe pas de moteur unique « capable de parler n'importe quel protocole ». Le système d'adaptateurs est le principal mécanisme d'extensibilité : prendre en charge un nouvel appareil revient à ajouter un nouvel adaptateur, ce que nous faisons sur demande (voir ci-dessous).

Chaque adaptateur est un module autonome responsable de :

1. La gestion de la connexion — établir et maintenir la communication
2. La récupération des données — récupérer les mesures à l'aide du protocole approprié
3. La transformation des données — convertir vers un format de métrique standardisé

Tous les adaptateurs héritent d'une classe de base qui fournit la surveillance de la santé, une logique de relance automatique, un backoff exponentiel en cas d'échec, la validation des métriques et la remontée d'état vers la plateforme IoT.

Gestion de la santé

Chaque adaptateur met en œuvre une machine à états automatique :

• INITIALIZING : démarrage et établissement des connexions initiales
• HEALTHY : fonctionnement normal avec des collectes de données réussies
• UNHEALTHY : présence d'erreurs, mais tentative de poursuite
• RECONNECTING : actions de récupération en cours après des échecs répétés
• FROZEN : l'appareil renvoie des données obsolètes — les mêmes valeurs se répètent, ou aucune nouvelle lecture n'est arrivée dans la fenêtre attendue
• PAUSED : mis en pause temporairement sur commande de l'utilisateur ; reprend automatiquement à l'expiration de la pause

Le système bascule automatiquement entre les états, remonte le statut à la plateforme et tente une récupération sans intervention manuelle. L'état FROZEN est ce qui permet à la plateforme de distinguer un logger réellement hors service d'un logger qui ne fait que répéter une valeur bloquée.

Appareils pris en charge

Le Data Scraper est livré avec une vingtaine d'adaptateurs spécifiques aux constructeurs, chacun conçu pour une famille d'appareils particulière. La liste ci-dessous reflète ce qui est pris en charge aujourd'hui et s'enrichit à chaque nouvelle intégration d'appareil.

Création de nouveaux adaptateurs

De nouveaux adaptateurs peuvent être développés pour prendre en charge des appareils ou protocoles supplémentaires. La conception modulaire et les fonctionnalités de la classe de base réduisent considérablement le temps de développement.

Compatibilité avec les équipements anciens : nous pouvons créer des adaptateurs pour des appareils plus anciens qui n'ont jamais été spécifiquement conçus pour l'export de données. Tant que l'appareil rend ses données accessibles d'une manière ou d'une autre — que ce soit via une API REST, une interface web, une base de données, un système de fichiers ou tout autre mécanisme — nous pouvons extraire ces données et les intégrer à la plateforme.

Collecte de données sans restriction : nos adaptateurs ne se limitent pas aux formats d'export de données prédéfinis que proposent habituellement les data loggers. Nous pouvons collecter toutes les données que l'appareil rend disponibles, au-delà de l'ensemble standard de métriques qu'un logger de constructeur expose. Si un appareil dispose d'informations de diagnostic supplémentaires, de paramètres avancés ou de points de données cachés accessibles via son interface, nous pouvons les récupérer et les standardiser.

Intégration via la plateforme

Pour un sous-ensemble d'appareils, vous pouvez mettre un logger en service depuis la plateforme sans écrire la moindre configuration à la main. Un assistant d'intégration demande à l'agent de réaliser une connexion à blanc à l'appareil et vous renvoie en direct les résultats de la sonde, de sorte que vous voyez immédiatement si la connexion fonctionne avant de la valider. Il existe deux variantes :

• Intégration sans configuration — l'adaptateur possède déjà l'ensemble complet des lectures de l'appareil, l'assistant se contente donc d'afficher un aperçu en direct en lecture seule et vous enregistrez. Disponible aujourd'hui pour dix-sept familles d'appareils : les compteurs Janitza, le Huawei SmartLogger, les contrôleurs Phoenix Contact, les onduleurs Fronius, les data loggers Solar-Log, SMA Sunny Central, SMA Power Manager, le logger Sungrow, Zebotec, Becker PV-Control (Prometheus), le stockage batterie FREQCON, Wattkraft Parkcontrol, les convertisseurs de batterie NR Electric, les batteries conteneurs Linyang/Xieneng les relais de protection SEG HighPROTEC, les batteries INTILION scalecube et l'automate d'alarme WAGO PFC200. Plusieurs d'entre elles — par exemple Janitza, Fronius et Wattkraft — ne nécessitent aucun identifiant ; SMA Power Manager et le logger Sungrow s'intègrent avec des identifiants d'appareil et signalent en outre automatiquement leur propre inventaire d'appareils (liste des composants, numéros de série, firmware) au lieu de le demander à la saisie. L'automate d'alarme WAGO est la seule exception à la voie rapide : rien sur le fil n'indique quel programme tourne sur une WAGO, il n'est donc jamais détecté automatiquement — il s'ajoute via Ajouter un logger, l'adaptateur et son profil d'intégrateur étant choisis à la main.
• Mappage interactif pour les loggers génériques — certains loggers exposent des valeurs brutes arbitraires que la plateforme ne peut pas interpréter d'elle-même. Pour ceux-ci, l'assistant demande à l'agent d'énumérer chaque valeur brute exposée par l'appareil (groupe, nom, unité, échantillon en direct), l'opérateur mappe chacune sur une métrique connue, et un essai à blanc piloté par le mappage prévisualise les métriques exactes qui seraient produites avant l'enregistrement. QReader et Bluelog sont intégrés de cette manière.

Standardisation des métriques

Toutes les données collectées sont transformées en un format de métrique standardisé défini par la taxonomie de métriques de la plateforme. Cela garantit la cohérence entre toutes les sources de données et permet un traitement unifié en aval.

Structure d'une métrique

Chaque métrique suit une structure standardisée compatible avec les bases de données temporelles modernes :

Composantes :

• Nom : identifiant de métrique standardisé issu d'une taxonomie prédéfinie
• Valeur : mesure numérique en unités SI de base
• Labels : paires clé-valeur pour l'identification et le regroupement des composants
• Horodatage : préservation facultative de l'horodatage d'origine de l'appareil

Labels standard :

• Type d'adaptateur source et numéro d'instance
• Noms lisibles par l'humain
• Identifiants de composant (ID d'onduleur, numéro de string, etc.)
• Localisation physique ou information de regroupement

Conventions d'unités

Toutes les métriques utilisent les unités SI de base, indépendamment de ce que rapporte l'appareil du constructeur :

• Puissance : watts (W)
• Énergie : wattheures (Wh)
• Tension : volts (V)
• Courant : ampères (A)
• Température : degrés Celsius (°C)
• Irradiance : watts par mètre carré (W/m²)

Les adaptateurs convertissent automatiquement les unités propres au constructeur (kW, MWh, etc.) vers ces standards pendant la phase de transformation.

Catégories de métriques

La plateforme définit 451 types de métriques standardisés organisés en 11 familles :

Les déploiements de labels (par string, par phase, par onduleur, etc.) démultiplient ces familles en bien plus de séries temporelles individuelles sur une installation réelle. Pour la taxonomie complète des métriques et leurs définitions, voir Collecte de métriques.

Flux de collecte de données

Stratégies de polling

Les adaptateurs prennent en charge deux modes de polling :

Basé sur un intervalle (par défaut) : s'exécute toutes les N secondes une fois la collecte précédente terminée. Simple et réactif face à des durées de collecte variables.

Basé sur des horaires fixes : s'exécute à intervalles fixes à partir de minuit, avec un décalage facultatif (par exemple à 00h01, 05h01, 10h01 pour des intervalles de 5 minutes avec un décalage de 1 minute). Utile pour s'aligner sur des systèmes externes.

Pipeline de traitement

Après la collecte, les métriques passent par plusieurs étapes de traitement :

Préparation des métriques : les labels source sont ajoutés, les horodatages appliqués et la structure validée.

Filtrage : les filtres configurés peuvent modifier les valeurs, valider des plages ou ignorer des métriques selon des règles.

Calculs : des calculateurs automatisés dérivent des métriques supplémentaires :

• Le rayonnement solaire intégré en énergie d'irradiation
• La tension de string × le courant calculés en puissance
• Les valeurs de puissance intégrées en énergie dans le temps

Découverte de composants : au fil du passage des métriques, le Data Scraper découvre et identifie automatiquement les composants de l'installation. Il s'agit d'une fonctionnalité essentielle — puisque le Data Scraper est la couche qui collecte activement les données, il sait intrinsèquement quels composants existent et fournissent des données. Le système découvre automatiquement :

• Les onduleurs (à partir des métriques de puissance d'onduleur)
• Les boîtes de jonction de strings / GAK (à partir des métriques de GAK)
• Les strings individuels (à partir des métriques de tension/courant de string)
• Les capteurs d'irradiation (à partir des métriques de rayonnement)
• Les points de raccordement réseau (à partir des métriques d'énergie réseau)

Les composants découverts sont synchronisés avec la plateforme IoT pour la gestion d'inventaire, créant un registre d'équipements en temps réel et auto-entretenu, sans configuration manuelle.

Détection de production : le système surveille l'état opérationnel de l'installation :

• Il détecte le début de la production sur la base de l'irradiance et de la puissance
• Il identifie les arrêts inattendus pendant les heures de production
• Il remonte les transitions d'état pour les alertes

Regroupement de métriques : les métriques sont regroupées par série temporelle afin d'optimiser les performances d'insertion en base de données.

Export des données

Les métriques traitées sont transmises à deux destinations :

Base de données temporelle : les métriques sont poussées par lots, avec limitation de débit et logique de relance, pour le stockage à long terme et l'interrogation historique.

Webhook Digital Twin : une tâche d'arrière-plan distincte transmet en continu les dernières valeurs de métriques au service Digital Twin (un microservice entièrement distinct) pour analyse en temps réel. Le Data Scraper ignore ce que fait le Digital Twin des données — il se contente de fournir les métriques. Pour plus d'informations sur le traitement du Digital Twin, voir Digital Twin.

Fonctionnement sans état

Le Data Scraper ne possède aucune base de données propre et ne conserve aucun état d'analyse entre les redémarrages :

• Peut être arrêté et redémarré sans perte de données
• Plusieurs instances peuvent s'exécuter indépendamment pour différents parcs
• Chaque cycle de polling est indépendant des cycles précédents
• Résistant aux pannes, sans risque de corrompre un état persistant
• Les mesures et remontées d'état qui ne peuvent pas être livrées — par exemple pendant une coupure internet — sont mises en tampon sur le disque local et livrées automatiquement au retour de la connectivité, de sorte que rien n'est perdu (la résilience « Rétention locale / Reprise automatique » décrite dans la Présentation du Mirox-Agent)

Le seul état persistant est le tampon local de livraison des données non encore transmises, auquel s'ajoute ce qui existe à l'extérieur :

• Fichiers de configuration (versionnés)
• Base de données temporelle (système externe)
• Registre de composants de l'IoT Cloud (système externe)

Cette conception garantit simplicité opérationnelle, fiabilité et mise à l'échelle horizontale aisée.

Séparation des responsabilités

Le Data Scraper a une responsabilité étroite et ciblée, ce qui permet une séparation nette des autres composants de la plateforme :

Data Scraper :

• Collecte les mesures brutes des équipements
• Transforme les données vers un format standard
• Découvre et suit les composants
• Surveille l'état d'activité des composants
• Surveille en direct la santé et l'état de connexion des composants, en ouvrant et clôturant des événements de parc
• Transmet les métriques aux autres services

Digital Twin : valide les données contre des modèles physiques et détecte les anomalies et les pertes

Base de données temporelle : stocke les données historiques et fournit une interface de requête

IoT Cloud : maintient le registre des composants, suit le statut des appareils et gère l'inventaire des équipements

Cette séparation permet le développement, les tests, le déploiement et la mise à l'échelle indépendants de chaque composant, tout en garantissant que chaque service se concentre sur son cœur de compétence.

Fonctionnalités avancées

Surveillance automatique de la santé

Chaque adaptateur met en œuvre une machine à états qui suit la santé opérationnelle, avec remontée automatique à la plateforme et exposition via l'API de métriques pour la supervision opérationnelle.

Découverte automatique des composants

La position du Data Scraper en tant que couche de collecte de données lui confère un avantage unique : il sait intrinsèquement quels composants existent sur une installation, car il interagit directement avec les métriques qu'ils produisent. Au fil du passage des métriques dans le système, les composants sont automatiquement découverts à partir des labels de métriques et enregistrés auprès de la plateforme IoT.

Processus de découverte :

1. Les métriques arrivent avec des labels d'identification (ID d'onduleur, numéro de string, localisation du capteur, etc.)
2. Le Data Scraper extrait les informations de composant à partir de ces labels
3. Les nouveaux composants sont automatiquement enregistrés auprès de l'IoT Cloud
4. Les métadonnées de composant (type, identifiant, localisation) sont synchronisées
5. La plateforme maintient un inventaire d'équipements à jour, sans saisie manuelle

Ce mécanisme d'auto-découverte garantit que la plateforme connaît toujours les équipements présents sur l'installation, éliminant le besoin de configuration manuelle et réduisant le temps de déploiement.

Détection de l'état de production

Le service surveille l'état opérationnel de l'installation et détecte les démarrages de production, les arrêts inattendus pendant les heures de production et les transitions d'état pour l'alerte et l'analyse, en ne remontant l'information que lorsque l'état change réellement. Il surveille également la surproduction — une sortie supérieure au modèle ciel clair sur une période prolongée — qui peut signaler un logger renvoyant des valeurs figées et, dans ce cas, bascule sur le modèle ciel clair afin que le flux de données reste cohérent. Cela offre une connaissance opérationnelle en temps réel allant au-delà des seules mesures brutes.

Métriques calculées

Plusieurs calculateurs dérivent automatiquement des métriques à partir des mesures brutes — le rayonnement solaire intégré en énergie d'irradiation, la puissance de string calculée à partir de la tension et du courant, et les valeurs de puissance intégrées en énergie dans le temps. Ces calculs ont lieu de manière transparente, enrichissant le flux de données sans nécessiter de configuration explicite.

Analyses edge

Au-delà de la collecte brute, le Data Scraper exécute un ensemble d'analyses directement sur l'installation, calculées à partir du flux de métriques en direct et exportées sous forme de séries temporelles traçables aux côtés des données brutes.

Puissance attendue et performance ratio

L'agent calcule en continu la puissance attendue de chaque installation et compare la production réelle à celle-ci sous forme de performance ratio (PR) — une mesure normalisée de l'efficacité de l'installation à convertir l'ensoleillement disponible en électricité. Plutôt que de se fier à une seule entrée, plusieurs sources d'irradiance indépendantes sont surveillées en parallèle, et chaque source dispose de sa propre série de PR — de sorte qu'un capteur sur site qui dérive ne peut jamais fausser silencieusement votre référence :

• Pyranomètre sur site — les capteurs d'irradiance propres à l'installation, disponibles en quasi-temps réel
• Satellite — l'irradiance dérivée du satellite pour la localisation exacte du site
• Modèle météo — l'irradiance modélisée à partir des données météorologiques

Conversion vers le plan des modules (POA). Toutes les sources sont converties en irradiance dans le plan des modules (POA, plane-of-array) — l'irradiance qui atteint réellement les modules — à l'aide de la hiérarchie de composants de l'installation (le Park Tree) : chaque string porte sa propre orientation, un azimut en degrés et une inclinaison, soit configurés par l'exploitant, soit détectés par le moteur d'analyse. L'irradiance horizontale est décomposée en ses parts directe et diffuse, puis transposée sur chaque plan de modules distinct à l'aide de la physique de position solaire standard du secteur, de sorte que des champs de modules orientés dans des directions différentes reçoivent chacun leur propre attente correcte. Les attentes des strings sont sommées en courbes par boîte de jonction et par onduleur, puis plafonnées à la puissance nominale AC de chaque onduleur.

Filtrage des anomalies. Avant qu'un instant donné ne puisse compter dans le PR fiable (« propre »), une batterie de filtres masque toutes les situations dans lesquelles un ratio faible ne signifierait pas un défaut :

Un PR par source. Le performance ratio est ensuite calculé séparément pour chaque source d'irradiance — publié à la fois en version brute (toutes les valeurs calculables) et propre (uniquement les valeurs filtrées et fiables) — au niveau du parc et par composant (onduleur, boîte de jonction, string). La moyenne glissante du PR propre auto-calibre en outre le modèle de puissance attendue : l'attente s'adapte automatiquement à l'efficacité réelle de chaque installation, et c'est cette même attente que le watchdog de santé des composants confronte à la production en direct.

Suivi de l'écrêtement en direct

Lorsqu'une installation produit moins qu'elle ne le pourrait, l'agent attribue la production manquée à sa cause : écrêtement par le marketer (un plafonnement délibéré dicté par le marché) par opposition à écrêtement par le gestionnaire de réseau. Cette distinction est importante pour la comptabilité des pertes et le reporting contractuel. L'écrêtement est suivi à la minute et émis à la fois sous forme de puissance instantanée et d'énergie cumulée. Voir Détection des pertes pour comprendre comment l'écrêtement s'inscrit dans l'attribution globale des pertes.

Référence ciel clair et prévisions

• Référence ciel clair : une courbe PV théorique en conditions idéales, conservée comme enregistrement à long terme, qui vous donne une référence stable pour comparer la sortie réelle.
• Prévision à un jour : une prévision de production PV à court horizon dérivée des données météo, qui vous permet d'anticiper la sortie du lendemain. Ces données reposent sur la physique de la météo, et non sur des estimations statistiques.

Backfill historique

Lorsqu'une installation est connectée pour la première fois ou après une interruption, l'agent peut rétro-remplir (backfill) les données historiques — en rejouant les lectures brutes et en re-dérivant les analyses ci-dessus pour une fenêtre demandée, puis en transmettant le résultat aux pipelines en direct, de sorte que les graphiques soient complets dès le premier jour plutôt que de partir vides.

Watchdog de santé des composants

Au-delà de la collecte de données, l'agent évalue en continu si chaque composant producteur — onduleurs, boîtes de jonction (GAK), strings et capteurs d'irradiance — est réellement en bonne santé, et transforme ses constats en événements de parc que vous voyez sur la plateforme. Deux questions sont posées en permanence : le composant est-il toujours connecté, et produit-il ce qu'il devrait ?

Surveillance de la connexion

La connectivité est suivie comme une chaîne causale stricte — liaison du parc, appareils réseau, data loggers, composants — et le watchdog différencie les manières dont une connexion peut tomber, chacune avec son propre événement :

Une seule alarme par cause racine. Chaque niveau ne lève des événements que tant que tous les niveaux au-dessus de lui sont sains : une panne à l'échelle du parc lève exactement un événement au niveau du parc et retient silencieusement tout ce qui se trouve en dessous, un switch mort lève un événement d'appareil, et ce n'est que lorsque le chemin réseau et le logger sont manifestement sains qu'un composant silencieux devient un défaut de composant. Toutes les transitions sont temporisées pour absorber les redémarrages et les brèves coupures, et chaque événement se clôture automatiquement au rétablissement, en indiquant la durée de la panne.

Contrôles de puissance et de production

En parallèle, le watchdog compare la puissance mesurée de chaque composant au modèle de puissance attendue sur de courtes fenêtres d'évaluation. Un zéro ou un déficit ne compte comme indice que lorsqu'une validation environnementale prouve que les conditions justifient une production — irradiance soutenue suffisante, pas de neige, de gel ni de brouillard, pas d'écrêtement effectivement contraignant, et un chemin réseau sain — de sorte qu'un sombre matin d'hiver ne peut jamais alerter personne.

Avant qu'une alarme ne s'ouvre, le constat est confronté à des témoins indépendants : les enfants du composant un niveau plus bas dans la hiérarchie, son propre compteur d'énergie cumulée, et un audit énergétique nocturne parent-versus-enfants. Le verdict décide du type d'événement que vous obtenez :

• Panne de production — le composant a réellement cessé de produire dans des conditions où il devrait produire
• Conflit de mesure — le composant produit bel et bien, mais sa propre mesure est fausse (un défaut de données à investiguer, jamais compté comme production perdue)
• Absence de communication — le composant a totalement cessé de remonter des données ; la production est inconnue et délibérément non comptée comme perte
• Production réduite — le composant produit, mais bien en dessous de son attente modélisée (jugé à la fois en direct et lors d'un audit nocturne sur la journée entière)

Les strings et les capteurs d'irradiance font l'objet d'investigations par étapes plutôt que de verdicts instantanés : un string silencieux ouvre d'abord une investigation de faible priorité et n'est confirmé comme panne ou défaut que sur une preuve de niveau physique — par exemple une sortie nulle sous un ciel couvert alors que ses voisins produisent — tandis que des zéros récurrents qui suivent la course du soleil sont reconnus et enregistrés comme de l'ombrage, pas comme un défaut. Un capteur dont le canal d'irradiance s'éteint alors que ses autres canaux restent actifs est signalé comme de l'encrassement (nettoyez le dôme) plutôt que comme un défaut matériel.

Signes vitaux des onduleurs

Les contrôles ci-dessus demandent si un onduleur produit encore. Une seconde série de contrôles demande si un onduleur qui produit se dirige silencieusement vers un défaut — en lisant les signaux que l'agent collecte déjà sur chaque onduleur mais n'a jamais utilisés pour le juger : température, résistance d'isolement, courants et tensions par phase, et le côté DC (tension et puissance).

Une voie de maintenance à part. Ces constats n'arrivent jamais comme une panne : l'onduleur produit, et rien n'est encore perdu. Ils s'ouvrent comme constats de maintenance, délibérément tenus à l'écart des événements de panne ci-dessus — les remontées de santé de routine d'un onduleur en production ne peuvent jamais clôturer un constat de maintenance, et un constat de maintenance ouvert ne peut jamais empêcher l'ouverture d'une véritable alarme de panne. Ils ne déplacent jamais non plus un chiffre de production : un onduleur porteur d'un constat de maintenance continue de compter comme producteur partout où la plateforme compte les composants qui produisent, puisqu'il produit.

Chaque constat est un événement à part entière. Il n'y a plus d'entrée générique « Maintenance requise onduleur » : chaque constat est remonté sous son propre nom parlant (Température élevée, Isolement en baisse, Déséquilibre de phases, Rendement en baisse), et chaque onduleur porte au plus un événement ouvert par constat. Plusieurs constats peuvent donc coexister sur la même unité, chacun avec son propre raisonnement, son propre historique et sa propre résorption, au lieu de fusionner dans une entrée unique qui dit seulement « il y a quelque chose à regarder ».

La surveillance est visible, le verdict attend. Un soupçon récent ne disparaît plus dans la comptabilité interne de l'agent. Dès qu'un contrôle a de quoi s'intéresser, il ouvre un événement d'observation de faible priorité — « Observation : température élevée », « Observation : déséquilibre de phases », etc., portant la même icône que le constat confirmé, dans une teinte plus claire. La liste d'activité de la centrale montre ainsi exactement ce que le système surveille, et depuis quand. Ce qu'un tel événement ne fait délibérément pas : modifier l'état de santé d'un composant. Les observations n'apparaissent jamais sur les vues de santé — pages d'analyse et de production, pastilles de composants, colonne des composants des stations et ses décomptes — car la plateforme n'y énonce un verdict que lorsqu'elle est sûre. Une observation est une piste, pas un verdict.

Une seule chaîne, du premier soupçon au constat. Lorsque la preuve confirmante arrive, l'observation est clôturée et le constat confirmé s'ouvre à sa place, en priorité normale, rattaché à l'observation dont il est issu. Les deux se lisent comme un seul historique — surveillé à partir de ce jour-là, confirmé à cette date — et la clôture de l'observation n'annonce aucune résorption, car rien n'a été résorbé : le constat a simplement changé d'étage. Ce n'est qu'à partir de la confirmation qu'il apparaît sur les vues de santé. Si la corroboration n'arrive jamais, l'observation se referme d'elle-même quand la condition disparaît, sans que rien n'ait jamais été affirmé.

Les événements de maintenance nomment le composant onduleur réel et portent le même raisonnement en langage clair que tout autre événement, avec les chiffres concrets derrière — l'excès mesuré, la comparaison aux unités voisines, le nombre de jours observés. Pour l'instant, ils sont délibérément silencieux : ils apparaissent dans la liste d'événements de la centrale mais restent sous tous les seuils de notification, le temps que les nouveaux contrôles soient calibrés sur les données réelles du parc d'installations. Événements de l'onduleur détaille ce qui ouvre, confirme et clôture chacun d'eux.

Preuves de cause sur les événements existants

Deux des signaux nouvellement lus ne créent pas d'événements propres — ils renforcent ceux qui existent déjà :

Côté AC ou côté DC ? Lorsque le watchdog ouvre une panne de production d'onduleur, il lit en plus la tension DC sur exactement les fenêtres diurnes pendant lesquelles l'unité n'a rien délivré. Un bus DC éteint signifie que la cause se situe côté DC (strings, appareillage DC) ; un bus sous tension signifie que le générateur est intact et que le défaut se trouve dans l'unité elle-même ou de son côté AC. Le verdict — côté AC, côté DC ou indéterminé — entre dans le raisonnement de l'événement de panne et décide quelle intervention vaut la peine d'être engagée. Le témoin dépend du fabricant : certains appareils — dont Huawei — ne signalent jamais un bus éteint ; là, il ne peut qu'innocenter le côté DC, jamais l'accuser.

Un écrêtement dû au réseau n'est pas un défaut. Lorsqu'un onduleur maintient sa tension AC à 1,10 fois sa tension nominale ou au-delà pendant une fenêtre de sous-performance, il limite sa sortie volontairement, suivant la règle volt-watt du code de réseau — il obéit au réseau, il ne défaille pas. Ces fenêtres sont tenues pour neutres au lieu d'être comptées comme un déficit, de sorte qu'un raccordement réseau tendu ne peut jamais s'accumuler en un faux défaut.

En combien de temps les événements sont-ils détectés ?

Ces détecteurs ne surveillent pas en continu. Ils s'exécutent une fois par nuit — plus une fois peu après le démarrage de l'agent — et reconstruisent leurs preuves à partir de l'historique enregistré à chaque passage. Une condition présente depuis des semaines est donc trouvée dès la première évaluation une fois son contrôle armé, et non des semaines plus tard. Ce qui prend du temps, c'est la preuve elle-même : chaque contrôle exige un historique minimal et une série de persistance avant de dire quoi que ce soit. La première colonne ci-dessous indique le moment où l'observation s'ouvre — faible priorité, visible dans la liste d'activité de la centrale, délibérément absente des vues de santé. La seconde indique ce qu'il faut pour que cette observation soit remplacée par le constat officiel, seul à apparaître sur ces vues.

Une centrale fraîchement raccordée voit donc ses premières observations de température au bout d'environ trois semaines et ses premières observations de rendement au bout d'environ deux mois, tandis que le témoin DC et l'exonération réseau fonctionnent dès le premier jour.

Deux limites méritent d'être connues :

• Un groupe de comparaison a besoin d'au moins six onduleurs comparables. Toutes ces règles sont relatives aux unités voisines — chaque appareil est jugé face à ses semblables, jamais face à un seuil absolu, car les limites absolues varient avec la taille du générateur et le fabricant. La conséquence est assumée : si tout un groupe de comparaison se dégrade de la même façon au même moment, cette dérive commune n'est pas détectable par cette méthode.
• La couverture est par onduleur et dictée par les données. Un contrôle ne s'arme que là où l'enregistreur du fabricant livre effectivement la métrique — aucun commutateur de configuration ne l'active. La couverture diffère donc d'une centrale à l'autre et d'un fabricant à l'autre.

Des événements qui s'expliquent d'eux-mêmes

Chaque événement porte un raisonnement en langage clair : ce qui a été mesuré, dans quelles conditions, quelles preuves indépendantes l'ont corroboré ou contredit, et ce qui le résoudrait. Les événements se clôturent automatiquement sur rétablissement prouvé, sont reclassés sur place lorsque les preuves changent d'avis (jamais d'aller-retour clôture-réouverture), et respectent vos décisions — un événement que vous clôturez reste clos jusqu'à ce que le défaut justifie de nouveau pleinement un nouvel événement. Un unique événement de synthèse « composants à l'arrêt » au niveau du parc porte la véritable alarme opérateur : il s'ouvre lorsqu'au moins un onduleur ou une boîte de jonction est à l'arrêt depuis une période prolongée, liste les composants concernés, et ne notifie qu'à la première ouverture et au rétablissement final.

Supervision réseau

Le Data Scraper intègre un inspecteur de réseau local qui s'exécute parallèlement à la collecte de données et cartographie le réseau sur site de l'installation. Il découvre les appareils sur les plages réseau configurées en balayant les hôtes joignables, en lisant la table d'adresses, en identifiant les constructeurs à partir des adresses matérielles et en sondant les appareils pour connaître leur identité. Les appareils découverts sont classés par rapport à une vaste bibliothèque de profils d'équipements réseau connus, et une étape d'identification d'appareil par IA aide à reconnaître des familles d'appareils que de simples règles ne détectent pas.

Une fois les appareils connus, l'inspecteur les interroge pour vérifier leur joignabilité et leur santé (temps de réponse, état des interfaces et des ressources) et remonte les résultats à la plateforme. Vous pouvez déclencher ou arrêter un scan de découverte, recontrôler un appareil individuel et passer en revue le réseau découvert — voir Inspecteur de réseau local.

Audit du proxy

Pour les installations accessibles via le Mirox Browser Proxy, l'agent audite les accès humains aux interfaces des appareils locaux. Il regroupe l'activité de chaque personne en sessions, expurge les données de requête sensibles avant tout stockage, et peut produire un résumé généré par IA de ce qu'une session a réalisé. Cela alimente la piste d'audit des accès de la plateforme — voir Journal d'audit des accès.

Caractéristiques de performance

Performances typiques :

• Fréquences de polling : 1 à 300 secondes par adaptateur (configurable)
• Adaptateurs concurrents : plus de 20 s'exécutant simultanément
• Débit : plus de 10 000 métriques par minute en continu
• Latence : moins de 100 ms entre la collecte et l'insertion en base de données
• Utilisation des ressources : 5 à 15 % de CPU, 100 à 500 Mo de mémoire sur du matériel edge

L'architecture asynchrone garantit une forte concurrence sans blocage, permettant une collecte efficace depuis de nombreuses sources simultanément.

Fonctionnalités associées

• Digital Twin — le moteur d'analyse basé sur la physique qui consomme les métriques collectées par le Data Scraper
• Présentation du Mirox-Agent — comment le Data Scraper s'intègre dans l'agent edge global
• Options de déploiement — les compromis entre déploiement sur site et déploiement cloud pour l'agent
• Collecte de métriques — la taxonomie complète et standardisée des métriques
• Inspecteur de réseau local — la surface de supervision du réseau sur site
• Détection des pertes — comment l'écrêtement et les autres pertes sont attribués
• Événements — comment les événements de parc du watchdog vous parviennent