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) 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
• 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 état : aucun état persistant entre les redémarrages
• 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 quinzaine 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 les compteurs Janitza, le Huawei SmartLogger et les contrôleurs Phoenix Contact. Janitza ne nécessite aucun identifiant.
• 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 est le premier logger générique pris en charge 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 376 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 est conçu pour être entièrement sans état :

• Aucun stockage persistant — tout l'état n'existe qu'en mémoire
• 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

Le seul état persistant 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
• 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 la puissance attendue de chaque installation à partir de ses sources d'irradiance (pyranomètre sur site, rayonnement satellite ou modèle météo) et la compare à la sortie réelle pour en dériver le performance ratio (PR) — une mesure normalisée de l'efficacité de l'installation à convertir l'ensoleillement disponible en électricité. Le PR est calculé par jour et tient compte de l'écrêtement, du gel et des filtres de qualité des données afin que les journées anormales ne faussent pas le résultat.

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.

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