Le défi de l'échelle

Cet article est le deuxième d'unesérie de huit articles publiés sur le site . Il traite des quatre principaux défis liés à la surveillance des performances solaires et des moyens de les surmonter.

Dans le premier article de cette série de huit articles sur la surveillance des performances solaires, nous avons abordé le défi que représente le fait de travailler avec des données d'exploitation réelles (c'est-à-dire imparfaites, désordonnées, "bruyantes"). De nombreuses applications de surveillance échouent lorsqu'elles tentent d'ingérer et de générer des informations à partir de données d'exploitation bruyantes. Dans ce deuxième article, nous abordons un autre défi commun que nous rencontrons lors de l'utilisation d'un logiciel de surveillance solaire : le défi de l'échelle.

DÉFINIR LE DÉFI DE L'ÉCHELLE

Par "échelle", j'entends que les applications de surveillance solaire doivent être capables de consommer de grands volumes de données à une vitesse élevée, provenant d'une grande variété de technologies :

• Volume : Le défi de laquantité de données
• Vélocité : Le défi de lavitesse des données
• Variété : Le défi de ladiversité des données

Issu du secteur de l'énergie traditionnelle, j'ai été surpris de constater que la classe d'actifs solaire génère plus de données qu'une centrale électrique fossile similaire. Les centrales électriques traditionnelles sont constituées d'équipements rotatifs, de chaudières et de systèmes de manutention du combustible importants et sophistiqués. On pourrait penser qu'une centrale fossile possède beaucoup plus de capteurs et de compteurs qu'une centrale solaire relativement simple de même taille ? Ce n'est pas le cas.

Volume

Comment cela se fait-il ? Bien que, d'un point de vue technique, les équipements solaires soient beaucoup plus simples que leurs équivalents fossiles, ils comportent beaucoup plus de générateurs (modules photovoltaïques) et de systèmes d'évacuation de l'électricité que les centrales à énergie fossile. Par exemple, une centrale solaire typique de 500 MW comporte plus de 100 fois plus de capteurs qu'une centrale au charbon de 500 MW.

Ajoutez à cela le fait que les propriétaires d'actifs solaires mettent en service des centrales à un rythme de plus de 120 fois le rythme des propriétaires d'énergie fossile. Vous commencez à voir l'ampleur de la montagne de données que nous devons escalader. Le client type de Power Factors génère plus d'un million de tags par heure et plus de 50 000 événements par jour. Cela fait beaucoup de données à traiter !

Vélocité

En même temps que nous nous attaquons au problème du volume élevé, nous devons également consommer ces données à une fréquence élevée. La fréquence des données dépend principalement des besoins des opérateurs solaires et de la réglementation.

Les centres d'opérations solaires à distance sont responsables de la surveillance en temps quasi réel de l'état de l'installation et des événements. La fréquence d'échantillonnage de cinq minutes est considérée comme le minimum requis par la plupart des opérateurs. Pour ceux qui doivent également surveiller l'état des disjoncteurs de l'installation et respecter les accords de niveau de service de réponse rapide conclus avec les propriétaires, cette fréquence peut même s'avérer trop faible.

 En outre, les opérateurs de réseaux et les régulateurs s'appuient de plus en plus sur les actifs d'énergie renouvelable pour fournir un soutien opérationnel au réseau, y compris le contrôle de la tension et de la fréquence. Pour répondre à ces exigences de réponse, de contrôle et de surveillance, on demande aux applications de surveillance des actifs de travailler avec des données inférieures à la minute, voire à la seconde.

Variété

S'il ne suffisait pas de relever les défis du volume et de la vitesse, le marché de l'énergie solaire est encore jeune. Cela introduit une grande variété de technologies avec lesquelles les systèmes de surveillance doivent travailler. Le secteur compte des dizaines de fabricants d'onduleurs, de suiveurs, de SCADA et de modules, chacun ayant ses propres protocoles de communication et codes d'alerte ouverts et propriétaires.

L'application de surveillance des actifs doit être capable de communiquer avec les exigences d'interface propres à chacun de ces fournisseurs, de faire correspondre les codes d'alerte à un ensemble commun de normes et de générer des événements significatifs et des analyses de performance.

Ce n'est pas une mince affaire. Les secteurs de l'énergie éolienne et de l'énergie fossile, comparativement plus matures, se sont regroupés autour de quelques fournisseurs d'équipements et ont adopté des codes de communication et de défaillance standard, ce qui a permis de réduire considérablement la diversité technologique observée dans ces catégories d'actifs. Le solaire n'en est pas encore là.

LA GESTION DE L'ÉCHELLE

Une application logicielle de qualité industrielle est nécessaire pour acquérir, traiter et analyser avec succès des données d'une telle ampleur. Les professionnels de l'informatique appellent cela une plateforme logicielle robuste et évolutive .

La robustesse d'un logiciel est synonyme de fiabilité et de disponibilité. La robustesse doit être intégrée dans la conception de la plateforme. L'infrastructure de la plateforme doit être hautement disponible et capable de maintenir les performances de l'application lors des tests de résistance.

Tech Terms définit l'évolutivité des logiciels comme "du matériel ou des logiciels évolutifs [qui] peuvent s'étendre pour prendre en charge des charges de travail croissantes. Cette capacité permet à l'équipement informatique et aux programmes logiciels de se développer au fil du temps, plutôt que de devoir être remplacés". Tout comme la robustesse, une plateforme évolutive doit être conçue dès le départ.

De nombreuses plates-formes logicielles de suivi solaire sur le marché n'ont pas été conçues avec ces capacités à l'esprit. Elles ont été conçues à l'origine pour répondre aux besoins des programmes d'incitation, dans le cadre desquels les organismes publics exigeaient un simple suivi de la production d'énergie pour démontrer que le projet solaire produisait de l'électricité à la hauteur de la note attribuée par le programme d'incitation. Ces applications de suivi n'ont jamais envisagé l'ampleur du marché ni les volumes de données que les plateformes logicielles d'aujourd'hui et de demain devront traiter.

Au fur et à mesure que l'échelle augmentait, de plus en plus de capacités ont dû être ajoutées à ces plates-formes pour tenter d'éviter que ces applications ne se cassent la figure. Le problème de cette approche est que le moteur fondamental d'acquisition et de traitement des données n'a pas été conçu pour supporter une telle échelle - le poids des ajouts finira par écraser le logiciel.

Nous devons repartir sur une base solide et évolutive en utilisant des outils et une infrastructure dorsale capables de s'adapter aux besoins croissants du marché.

RÉSUMÉ

Le défi de l'échelle est débilitant pour la plupart des applications logicielles de contrôle solaire, simplement parce qu'elles n'ont pas été conçues pour traiter le volume, la vitesse et la variété des données qui leur sont envoyées. Tant que ce problème fondamental ne sera pas résolu, les utilisateurs continueront d'être frustrés par des outils de surveillance logiciels qui tombent trop souvent en panne.

Vous souhaitez en savoir plus sur la façon dont la plateforme de gestion de la performance des actifs (APM) Drive Pro de Power Factors vous aide à relever le défi de l'échelle ?

Steve Hanawalt est vice-président exécutif et fondateur de Power Factors.