Événements

Les événements sont les signaux détectés par machine que vos centrales remontent d'elles-mêmes — une coupure réseau, un plafonnement de surproduction, un logger qui perd le contact avec sa source. Ils vous fournissent un relevé objectif et horodaté de ce qui s'est passé, afin que vous puissiez réagir rapidement et prouver plus tard ce que la plateforme a observé, et quand.

Le concept d'événement

Un événement est créé automatiquement lorsque la plateforme reconnaît une condition notable sur une centrale. La plupart des événements proviennent du Jumeau Numérique et des agents de supervision surveillant chaque centrale ; d'autres sont émis comme effet secondaire de changements de configuration (par exemple, lorsqu'un data logger est ajouté ou mis en pause). Vous pouvez aussi enregistrer vous-même un événement pour quelque chose que vous avez observé sur site.

Les événements sont volontairement légers : chacun capture ce que la plateforme a détecté, où, quand et avec quelle gravité. Le côté humain de l'histoire — notes de triage, qui s'en occupe, ce qui a été fait pour corriger — réside dans les Tickets, et non dans l'événement lui-même.

Types d'événements

Chaque événement porte un type qui vous indique ce qui a été détecté. Les types se répartissent en quelques familles :

Production et réseau

• Coupure réseau : la production a été écrêtée ou arrêtée par le gestionnaire du réseau électrique.
• Coupure externe : la production a été arrêtée par une instruction externe (par exemple, un agrégateur de vente directe ou un écrêtage à distance).
• Surproduction : la centrale a dépassé son niveau de production attendu ou autorisé.

Santé des composants — levés par le watchdog de santé des composants de la centrale. Chaque type porte le nom du composant sur lequel il se pose : un onduleur, une boîte de jonction et un string ont chacun leur version du même constat. Pour les onduleurs, Événements des onduleurs détaille chacun d'eux — ce qui l'ouvre, ce qui le confirme et comment il se ferme.

Production — un seul de ces événements se tient à la fois sur un composant :

• Panne de production onduleur : production nulle confirmée dans des conditions justifiant une production.
• Conflit de mesure onduleur : l'onduleur produit, mais sa propre mesure est fausse — un défaut de données à investiguer, jamais compté comme production perdue.
• Onduleur sans communication : l'onduleur a cessé de remonter des données — sa production est inconnue, délibérément non comptée comme perte.
• Production réduite onduleur : l'onduleur produit, mais bien en dessous de son attente modélisée.

Et une synthèse au niveau du parc, qui se pose au-dessus des événements de composant plutôt qu'à leur place :

• Synthèse des pannes de composants : l'unique synthèse de haute priorité au niveau du parc qui liste tous les onduleurs et boîtes de jonction actuellement à l'arrêt — c'est ce récapitulatif qui porte l'alarme opérateur.

Constats de maintenance — un onduleur qui produit à pleine puissance pendant que quelque chose s'use. Chacun s'ouvre d'abord comme une ligne Observation : … et devient un constat confirmé une fois les indices réunis :

• Température élevée onduleur : il chauffe sensiblement plus que des unités comparables du même logger, à charge égale.
• Isolation en baisse onduleur : son relevé d'isolement matinal stabilisé passe durablement sous celui de ses pairs.
• Déséquilibre de phases onduleur : les trois phases CA ne portent plus le même courant.
• Rendement en baisse onduleur : la perte de conversion CC-CA augmente de mois en mois, au-delà de ce qu'expliquent la charge et la température.

État de l'appareil — ce que la machine dit de son propre état, un événement par mode :

• Défaut d'appareil onduleur : l'onduleur signale un défaut qui lui est propre, dans une fonction dont la plateforme n'a aucune mesure — matériel, firmware, licence, configuration, arrêt d'urgence, string continu ou comptage. Une intervention, pas une perte de production.
• Le logger n'atteint pas l'onduleur : le logger déclare qu'il n'arrive pas à atteindre la machine alors qu'aucun relevé de notre côté ne nous en parvient non plus. Un relevé d'arrière-plan discret — il ne notifie personne et ne pose aucun état sur l'onduleur ; après une heure de plein jour, il est repris par un événement sans communication.
• Alarme de sécurité onduleur : un défaut d'arc ou une condition de courant résiduel signalés par l'appareil — ouverts sur un unique signalement actif, de jour comme de nuit.
• Arrêt de protection onduleur : une protection a déclenché la machine ; elle peut nécessiter un redémarrage manuel sur site.
• Onduleur arrêté sur commande : il a été arrêté délibérément, par une personne ou par une instruction à distance.
• Autolimitation onduleur : il produit mais se bride pour se protéger, le plus souvent contre la chaleur.
• Défaut d'appareil batterie : le même relevé pour un convertisseur de batterie ou un BMS de conteneur — les signalements de communication d'une batterie restent ici, elle n'a pas de relevé d'accessibilité séparé.

Miroir des signalements de l'appareil — la liste d'alarmes actives du constructeur, recopiée telle qu'envoyée et jamais jugée :

• Défaut signalé par l'onduleur / Avertissement signalé par l'onduleur (et les deux équivalents batterie) : un relevé par code, ouvert lorsque l'appareil le lève et fermé lorsqu'il le retire.

Santé des capteurs — une chaîne par étapes, afin qu'un capteur sain ne soit jamais condamné sur des preuves fragiles :

• Investigation de capteur : un canal d'irradiance a cessé de fournir un signal exploitable — sous observation.
• Défaut de capteur : le défaut est corroboré par des preuves indépendantes — remplacez le capteur.
• Encrassement de capteur : le dôme du capteur est sale ou couvert de neige — nettoyez-le ; l'événement escalade en défaut s'il ne se rétablit pas.

Investigations de strings — la même approche par étapes pour les strings :

• Investigation de string : un string présente des zéros inexpliqués dans des conditions justifiant une production — sous observation.
• Panne de string / Défaut de string : l'investigation a été confirmée — un string mort, ou un string produisant bien en dessous de ses voisins sans se rétablir.
• Ombrage de string : les zéros du string se répètent en suivant la course du soleil — enregistrés discrètement comme de l'ombrage, pas comme un défaut.

Connexion et disponibilité — une seule alarme au niveau où se situe la cause racine :

• VPN hors ligne : le tunnel de supervision vers la centrale est coupé.
• Réseau du parc hors ligne : le réseau local de la centrale est injoignable.
• Appareil réseau hors ligne : un seul appareil réseau supervisé a cessé de répondre.
• Panne massive d'appareils réseau : une grande partie des appareils de la centrale est passée hors ligne en même temps.

Écrêtement et règlement — voir Règlement de l'écrêtement pour l'explication complète :

• Écrêtement détecté : le relevé en direct de chaque épisode d'écrêtement, avec son début, sa fin et sa limite réels.
• Enregistrements de règlement : la comptabilité derrière l'indemnisation — un événement de règlement par mesure d'écrêtement avec la méthode légale et les chiffres, une valeur mensuelle par centrale, et des événements de révision pour les corrections ultérieures des prix officiels.

Intégrité de l'énergie

• Compteur d'énergie figé : le registre d'énergie cumulée d'un appareil a cessé d'avancer alors qu'il continue de produire — son propre relevé de production doit être réparé.
• Énergie d'injection estimée : une partie de la série d'injection de la centrale est temporairement estimée à partir des relevés de puissance.

Acquisition de données et configuration

• Disponibilité des sources : une source de données est devenue injoignable ou s'est rétablie (interruption d'acquisition de données).
• Cycle de vie du logger : un data logger a été créé, mis à jour, mis en pause, repris, supprimé, ou a vu ses identifiants modifiés.
• Créé par l'utilisateur : un événement que vous avez enregistré manuellement pour une condition observée.

Priorité d'événement

Chaque événement porte un niveau de priorité afin que vous puissiez vous concentrer d'abord sur ce qui compte :

Statut d'événement

Les événements suivent un cycle de vie court et clair :

• Détecté : l'événement vient d'être remonté et n'a pas encore été examiné.
• Reconnu : quelqu'un a vu l'événement et l'a accepté pour suivi.
• Clôturé : la condition sous-jacente est résolue. De nombreux événements se clôturent automatiquement — par exemple lorsqu'une source écrêtée se reconnecte, qu'une coupure prend fin ou que la surproduction s'atténue — tandis que d'autres sont clôturés manuellement une fois le travail terminé.

Les événements clôturés peuvent être rouverts si la condition réapparaît, afin qu'un problème récurrent conserve son historique regroupé.

Liaison et suivi

Les événements ne sont pas isolés. Vous pouvez relier chaque événement aux parties de la centrale qu'il concerne et au travail nécessaire pour le résoudre :

• Liens vers les composants : rattachez un événement aux composants spécifiques qu'il affecte (un logger, un onduleur, un GAK, un string, un compteur d'injection ou un capteur), et recherchez parmi les composants de la centrale pour trouver le bon.
• Liens vers les tickets : référencez un événement depuis un ticket afin que l'investigation, l'affectation, les commentaires et la résolution soient suivis au même endroit.
• Suivi des notifications : chaque événement enregistre quels utilisateurs ont été notifiés et qui l'a vu.

Suivi des coupures

Les événements de coupure réseau et de coupure externe sont également regroupés dans une vue dédiée aux pertes de production. Filtrée par centrale et par portefeuille, elle vous permet de voir à quelle fréquence la production a été interrompue et d'attribuer l'énergie perdue — une donnée directe pour les revues de performance et le reporting. Consultez la Détection des pertes pour savoir comment la production interrompue est quantifiée.

Trouver et examiner les événements

Les événements sont conservés sous forme d'historique à long terme afin que vous puissiez à la fois réagir sur le moment et analyser les tendances plus tard :

• Liste et filtres : parcourez les événements de toutes les centrales auxquelles vous avez accès, filtrés par centrale, portefeuille, type, statut ou priorité, et triés pour faire remonter les plus récents ou les plus urgents en premier.
• Compteurs : des compteurs en un coup d'œil résument combien d'événements sont ouverts et comment ils se répartissent, alimentant le Tableau de bord KPI.
• Vue détaillée : ouvrez n'importe quel événement pour voir son contexte complet, les composants liés, les tickets liés et l'historique des notifications.
• Relevé historique : les événements clôturés restent disponibles pour les audits, les réclamations de garantie et l'identification de schémas récurrents dans le temps.

Accès et autorisations

Les événements sont une sous-ressource de la centrale, l'accès suit donc votre rôle sur la centrale parente — et non un réglage distinct. Toute personne pouvant consulter une centrale peut voir ses événements. Au-delà :

• Rôles techniques — les Exploitants et les Technical Manager bénéficient d'une gestion complète des événements : reconnaître, créer, clôturer et supprimer.
• Asset Manager (Commercial) peut créer et reconnaître des événements pour la supervision commerciale, mais ne peut pas les supprimer.
• Spectateurs ont un accès en lecture seule.

Les coopérateurs qui détiennent le rôle de mission requis sur une centrale partagée sont inclus aux mêmes conditions. Consultez le Système d'autorisations pour le modèle de rôles complet.

Fonctionnalités associées

• Tickets — l'espace de travail humain de suivi où les événements sont triés et résolus
• Événements des onduleurs — tous les événements de santé de composant qu'un onduleur peut porter, en détail
• Jumeau Numérique — le moteur d'analyse qui détecte la plupart des événements
• Détection des pertes — quantifie la production perdue pendant les coupures
• Tableau de bord KPI — fait remonter les compteurs d'événements aux côtés des indicateurs de performance
• Rapports — intègre les données d'événements et de pertes de coupure dans la documentation périodique