Commande BESS : vérifier les ordres et la réponse de la batterie

Une batterie peut accepter une commande sans fournir la puissance demandée. La requête peut attendre dans une file, être refusée par le PCS, être limitée par les protections de la batterie ou être supplantée par un autre contrôleur. Consignez chaque étape séparément. Si un agrégateur conteste un déficit de fourniture, cet historique indique à quelle étape il s’est produit.

Ce guide fait partie du parcours sur la flexibilité. Le guide des rôles du BESS précise les responsabilités du BMS, du PCS et de l’EMS.

Définir ce qui constitue une fourniture effective

Concluez un accord sur le compteur, la convention de signe, la fenêtre temporelle et la tolérance avant le premier essai.

Le compteur peut se trouver aux bornes de la batterie, au point de raccordement du site ou au compteur réseau. Chaque emplacement donne un résultat différent. Entre les bornes et le raccordement, l’onduleur, le transformateur et les câbles ont des pertes. Au compteur réseau, toutes les autres charges du site varient également. Si le service juge la fourniture à ce compteur, il lui faut une référence : ce que le site aurait fait sans commande. Pour les services dynamiques britanniques, la référence opérationnelle est une Physical Notification, en GMT toute l’année, à une résolution d’une minute ou meilleure, fixée à la fermeture du guichet 60 minutes avant chaque période de règlement de 30 minutes. Les programmes de réponse à la demande utilisent souvent une référence historique ; le guide des références de consommation présente ces méthodes.

Inscrivez la convention de signe dans le dossier. Les tables de registres PCS prennent souvent la décharge comme positive, selon la convention des générateurs. Un compteur de site suivant la convention des charges prend l’importation comme positive : la même décharge apparaît donc comme une puissance négative ou une baisse de l’importation. Si un élément de la chaîne inverse le signe, une décharge correcte de 500 kW apparaît comme une erreur de 1 000 kW par rapport à la demande.

Un service peut fixer lui-même la fenêtre et la tolérance. Les instructions de NESO destinées aux fournisseurs de services dynamiques britanniques établissent les limites suivantes :

NESO évalue chaque période de règlement de 30 minutes, soit 36 000 lignes à 20 Hz. Pour DC et DM, une erreur doit persister sur une fenêtre glissante de 0,2 s (quatre échantillons) pour être comptée ; la plus importante de ces erreurs sur la période détermine le facteur de performance. Une unité qui se déclare disponible sur moins de 99,9 % des lignes ne reçoit aucun paiement de disponibilité pour cette période. Les lignes manquantes ou mal horodatées ont donc un coût, indépendamment de la réponse elle-même. Ces services suivent localement la fréquence, donc la chaîne de commande est courte, mais le même journal d’étapes s’applique à la consigne calculée par le contrôleur local.

Pour un service piloté sans règles publiées, inscrivez des chiffres dans le contrat. Par exemple : pleine puissance dans les 5 s suivant la commande, maintenue 30 minutes, évaluée sur des moyennes d’une minute dans une tolérance de ±3 % de la demande, au compteur du départ batterie.

Étapes d’une commande

Chaque accusé de réception de protocole ne couvre qu’un maillon. HTTP 202 Accepted signifie que la requête a été acceptée pour traitement, lequel n’est pas terminé. MQTT PUBACK accuse réception d’un PUBLISH en QoS 1. En MQTT 5, vérifiez son Reason Code : une valeur supérieure ou égale à 0x80 indique un refus. Un PUBACK positif du broker confirme l’acceptation par ce broker, pas la réception par un abonné ni une action de la batterie. QoS 0 n’a pas d’accusé de réception ; QoS 2 utilise PUBREC, PUBREL et PUBCOMP.

L’écriture d’un registre Modbus (fonction 06) renvoie un écho de la requête. L’écriture de plusieurs registres (fonction 16) renvoie l’adresse de départ et le nombre de registres écrits. Cet écho prouve que l’appareil a traité la trame. Beaucoup de PCS acceptent l’écriture, puis limitent ou ignorent la valeur parce qu’elle est hors plage, que l’unité est en mode local ou qu’une autre source a priorité. Relisez le registre de consigne active pour confirmer l’état. Sur de nombreux PCS, il est distinct de celui de la valeur demandée. Aucun de ces accusés ne mesure la puissance de la batterie.

Tenir un journal corrélé

Pour chaque commande, consignez :

• son identifiant, l’équipement cible et le système demandeur ;
• la valeur demandée, son unité et sa convention de signe ;
• l’heure d’émission et l’heure d’expiration ;
• chaque accusé de réception avec son heure, rattaché à cet identifiant ;
• la consigne active relue et le mode du PCS ;
• l’état de charge et les puissances de charge et décharge autorisées à cet instant ;
• la puissance mesurée par le compteur convenu, horodatée à l’heure de mesure, pas à celle de réception.

Synchroniser les horloges

Le journal ne permet de corréler les événements que si tous les appareils partagent la même référence temporelle. L’heure de commande vient de la plateforme, celle d’écriture de la passerelle et celle de l’échantillon du compteur. Si ces horloges diffèrent de 300 ms, une réponse DC commencée à temps paraît tardive face à une limite de début de 0,5 s.

Sur un réseau Ethernet local peu chargé, NTP maintient une horloge à environ 100 µs près. Sur une liaison Internet intercontinentale, l’erreur peut atteindre plusieurs dizaines de millisecondes, voire 100 ms ou davantage si les trajets sont asymétriques. Pour des données à 20 Hz, utilisez une source de temps sur le site : récepteur GNSS ou serveur NTP du réseau local asservi au GNSS. Horodatez les mesures en UTC au point de mesure. Les fichiers de performance de NESO rejettent les lignes dont l’horodatage n’est pas un multiple exact de la période d’échantillonnage, soit 50 ms à 20 Hz.

Exemple chiffré

Un agrégateur demande une décharge de 500 kW, à commencer immédiatement et à maintenir pendant 30 minutes. Le compteur convenu est celui du départ batterie. Les critères retenus sont la pleine puissance sous 5 s et des moyennes d’une minute à ±3 % (15 kW). Le PCS prend la décharge comme positive. Ces chiffres sont illustratifs.

Pendant cette même minute, l’importation au compteur réseau a baissé de 440 kW, et non de 500 kW. Un groupe frigorifique de 55 kW a démarré à 14:00:40, comme le montre son sous-compteur ; environ 5 kW ont été perdus dans le transformateur et les câbles. Évaluée au compteur réseau sans référence de consommation, la même réponse paraît fournie à 88 %.

Reproduisez maintenant la commande avec un état de charge de 11 %. L’écho de l’écriture reste identique. La relecture indique une consigne active de 300 kW et une décharge autorisée de 300 kW. Le journal montre la limitation à l’étape de confirmation d’état, avec sa raison, environ 1 s après la commande. Sans cette relecture, le déficit n’apparaîtrait qu’au règlement.

Délais d’attente et nouvelles tentatives

Un dépassement de délai laisse le résultat inconnu. La batterie peut avoir agi alors que sa réponse s’est perdue. Avant tout nouvel essai, relisez la consigne active et la puissance mesurée.

Concluez par écrit avec le fournisseur du PCS les règles de traitement des commandes. Attribuez un identifiant à chacune. Si le PCS possède un registre d’identifiant ou de séquence de commande, écrivez-le avec la consigne et relisez-le : une commande répétée avec le même identifiant n’aura pas de second effet. Une nouvelle commande remplace l’ancienne, la dernière écriture l’emporte et la relecture indique laquelle est en vigueur. Annulez par une commande explicite, généralement une puissance nulle ou un retour en mode local, pas par le silence. MQTT QoS 1 livre au moins une fois. Une commande applicative répétée peut arriver avec DUP=0 ; DUP signale la retransmission d’un paquet MQTT et ne permet pas de reconnaître de façon fiable un doublon applicatif. Dédupliquez selon l’identifiant de commande applicatif, indépendamment de DUP.

Ne rejouez jamais une commande expirée simplement parce qu’une connexion est rétablie. Une demande de décharge qui arrive dix minutes en retard devient une décharge non demandée. Vérifiez l’expiration chez le destinataire, au moyen d’une horloge synchronisée : lui seul sait quand la commande est arrivée. Deux fonctions MQTT peuvent délivrer une ancienne consigne après reconnexion : un message conservé, que le broker envoie à tout nouvel abonné, et une session persistante, qui garde des messages QoS 1 et QoS 2 pour un client déconnecté. Avec MQTT 5, Message Expiry Interval fait supprimer au broker une copie dont il n’a pas commencé la livraison après l’expiration du délai. Il n’arrête pas un message dont l’envoi a commencé avant l’expiration, ni un message mis en file par une passerelle. Placez l’heure d’expiration dans la charge utile et vérifiez-la au Gateway.

Le PCS doit posséder sa propre limite sur une consigne périmée. Beaucoup de PCS disposent d’un chien de garde de communication : si le contrôleur ne rafraîchit pas un registre de vie dans le délai fixé, le PCS revient à un état de repli. Le modèle SunSpec 123 pour les commandes immédiates donne à la limite de puissance son propre délai de retour, WMaxLimPct_RvrtTms. Convenez du repli par écrit : puissance nulle, programme de l’EMS local ou maintien de la dernière consigne pendant une durée fixe. Le maintien est l’option dangereuse, car une liaison perdue laisse la décharge en cours.

Rendre visibles les contraintes

Enregistrez les puissances de charge et de décharge autorisées par le PCS avec chaque commande, pas seulement en cas d’échec. Quand la batterie ne peut pas fournir la puissance, affichez la raison qu’elle rapporte : état de charge, limite de puissance, réduction liée à la température, alarme, mode maintenance ou contrôleur plus prioritaire. Si la batterie ne fournit aucune raison, indiquez « inconnue ». N’en déduisez pas une.

Concluez un accord sur le contrôleur prioritaire lorsque programme, demande de l’agrégateur et limite locale divergent. Maintenez les protections de la batterie et les verrouillages du site. Une passerelle ne doit jamais contourner un verrouillage pour faire paraître réussie une commande distante.

Séquence d’essais de mise en service

Menez chaque essai en présence du propriétaire de l’équipement et conservez son journal d’étapes.

1. Commande normale. Décharge dans les limites. Réussite : toutes les étapes portent le même identifiant et le compteur convenu atteint la demande dans le délai et la tolérance fixés.
2. Commande limitée. Demande supérieure à la puissance de décharge autorisée. Réussite : la relecture montre la consigne limitée, le journal en consigne la raison et la puissance mesurée correspond à cette limite.
3. Doublon. Envoyez deux fois le même identifiant. Réussite : la batterie agit une seule fois.
4. Expiration. Livrez une commande après son heure d’expiration. Réussite : le Gateway la refuse et consigne le refus ; la batterie garde sa consigne actuelle ou son état de repli.
5. Panne de liaison. Coupez la liaison pendant une décharge. Réussite : le PCS revient au repli convenu dans le délai du chien de garde. Lorsque la liaison revient, la batterie ne reprend pas l’ancienne consigne.
6. Redémarrage. Redémarrez le Gateway ou l’EMS pendant une commande. Réussite : la consigne en vigueur après redémarrage est le repli ou une commande non expirée, et le journal indique laquelle.
7. Contrôleur concurrent. Appliquez une priorité locale pendant une commande distante. Réussite : la priorité locale l’emporte et le système distant note que sa commande a été supplantée, avec la raison.

Le guide de commande locale transforme ces cas en matrice de défaillance pour le site entier.

Commande de batterie avec EpiSensor

Le ZDR-22 est la variante de commande de batterie du contrôleur de réponse à la demande ZDR. Il suit la fréquence du réseau, envoie une consigne variable à une batterie ou une alimentation sans interruption par Modbus RTU et mesure l’alimentation en classe 0,5S. Il enregistre les événements toutes les 20 ms avec des horodatages GPS. La consigne envoyée et la réponse mesurée partagent donc la même horloge, ce qui couvre les étapes de commande et de résultat du tableau précédent.

Un Gateway exécutant Edge peut interroger par Modbus les registres du PCS, notamment la consigne active et la puissance autorisée, ainsi que les compteurs du site. Il horodate chaque lecture au moment où il l’effectue et garde l’historique sur le Gateway : une perte de liaison avec la plateforme ne crée donc pas de lacune dans le journal local. Edge Automation fonctionne sur le Gateway et applique la règle d’expiration à ses propres actions programmées. Après un redémarrage, il n’envoie une commande de fin enregistrée que jusqu’à cinq minutes après son échéance. Au-delà, il ne la rejoue pas. Il signale la commande expirée et demande de vérifier l’équipement.