Une mise à jour du firmware de l'onduleur n'est complète que lorsque les fonctions requises du projet ont été vérifiées, et non lorsque la barre de progression est terminée. L'appareil peut redémarrer normalement alors qu'un paramètre d'exportation, une interface de batterie, une configuration parallèle ou un comportement de secours a changé. Un téléversement réussi prouve que le logiciel a été installé ; il ne prouve pas que l'installation fournit toujours le service contractuel.
Pour les EPC et les distributeurs, traitez la mise à jour comme un changement d'ingénierie contrôlé. Documentez la raison, confirmez la combinaison exacte matériel/firmware, enregistrez la configuration approuvée et déterminez quelles fonctions doivent être retestées. Appliquez les mises à jour urgentes de sécurité ou exigées par le fabricant dans le cadre d'une analyse de risque appropriée ; n'utilisez pas le contrôle des changements comme prétexte pour ignorer une instruction de sécurité ou de sûreté.
Définir la raison de la version
Distinguez une correction de sécurité, un changement exigé par le fabricant, un remède à un défaut et une nouvelle fonctionnalité. Chacun a une justification différente et peut nécessiter une planification différente. Une fonctionnalité sans rapport avec le projet ne constitue pas, en soi, une preuve qu'une installation en exploitation bénéficie d'une mise à niveau immédiate.
Avant de mettre à jour un onduleur solaire HMX, demandez les notes de version applicables et la procédure de mise à jour prise en charge pour son modèle et sa révision matérielle exacts. Confirmez toute dépendance impliquant le BMS de la batterie, le compteur, la passerelle de communication ou le contrôleur. Ne supposez pas qu'un fichier destiné à un modèle similaire soit acceptable.
Désignez une personne nommée pour autoriser le changement et une personne nommée pour confirmer le résultat. Dans un petit projet, il peut s'agir de membres de la même équipe d'installation, mais les responsabilités doivent tout de même être consignées. Le client doit savoir si la mise à jour interrompt le service et quelles dispositions temporaires sont nécessaires.
| Consigner | Informations requises | Décision de version qu'elles appuient |
|---|---|---|
| Objet | Correction, exigence ou fonctionnalité de projet pertinente | Pourquoi ce changement est nécessaire |
| Identité de l'équipement | Modèle, numéro de série, matériel et versions logicielles installées | Si le fichier cible s'applique |
| Dépendances | Versions prises en charge de la batterie, du compteur, du contrôleur et des dispositifs parallèles | Si la combinaison système est prise en charge |
| Référence de configuration | Paramètres approuvés d'exportation, de secours, de charge et d'accès | Ce qui doit rester correct après la mise à jour |
| Fenêtre de service | Interruption prévue et dispositions pour le client | Quand le changement peut avoir lieu en toute sécurité |
| Voie de récupération | Contacts de récupération et d'assistance approuvés par le fabricant | Comment un changement infructueux sera géré |
Ne supposez pas que chaque mise à jour préserve les paramètres
Une comparaison utile provient de deux documents actuels au sein de la même bibliothèque du fabricant. Le guide général du firmware VictronConnect décrit la préservation des paramètres applicables et de l'historique, tout en orientant explicitement les produits VE.Bus vers un guide distinct. La lecture du seul énoncé général manquerait une limite importante propre au produit.
Le guide VictronConnect distinct pour les produits VE.Bus avertit que son processus de mise à jour réinitialise les paramètres aux valeurs d'usine et exige la reprogrammation des configurations multi-unités. Ce comportement est spécifique aux produits et au processus documentés ; il ne constitue pas une affirmation concernant les équipements HMX.
La leçon en matière d'approvisionnement est simple : demandez si ce modèle et cette méthode de mise à jour préservent, migrent ou réinitialisent chaque paramètre pertinent. Enregistrez une exportation de configuration lorsqu'elle est prise en charge, ainsi que des enregistrements lisibles par l'homme des paramètres essentiels. Un fichier qui ne peut pas être restauré vers la nouvelle version ne constitue pas un plan de récupération complet.
Enregistrez les valeurs approuvées actuelles plutôt que de copier les valeurs par défaut d'un manuel. Les valeurs par défaut peuvent ne pas correspondre à l'approbation réseau du site, aux limites de la batterie ou à la conception du secours. La restauration d'une ancienne configuration nécessite également un examen si la nouvelle version modifie la signification ou la plage prise en charge d'un paramètre.
Construisez le retest autour de ce que le projet utilise réellement
Choisissez les tests de régression avant d'installer la mise à jour. Incluez les fonctions concernées par les notes de version et les fonctions dont la défaillance importerait au client. Un projet de stockage peut dépendre des autorisations de charge de la batterie et des transitions de secours même lorsque la mise à jour est décrite comme une amélioration des communications.
Cartographiez d'abord les relations entre équipements. La distinction entre fonctions BMS, de conversion de puissance et de gestion de l'énergie aide à identifier quel dispositif fournit une limite ou une commande d'exploitation. Un chiffre visible sur l'écran n'établit pas que l'onduleur suit la dernière valeur autorisée.
| Fonction utilisée par le projet | Point de vérification | Preuve à conserver |
|---|---|---|
| Fonctionnement de la batterie | Communications, limites actives de charge/décharge et gestion des alarmes | Versions d'appareils correspondantes et enregistrements d'exploitation observés |
| Contrôle des exportations | Interprétation du compteur, point de consigne et réponse conformément à l'arrangement approuvé | Paramètres et résultat de test mesuré |
| Alimentation de secours | Transfert approuvé, charges réelles et retour au réseau | Chronologie des événements et observations de service |
| Fonctionnement parallèle ou multiphasé | Combinaison de versions prise en charge et rôles configurés | Topologie et résultats fonctionnels approuvés |
| Surveillance à distance | Télémétrie actuelle, alarmes et accès autorisé | Horodatages récents et chemin de notification testé |
| Répartition planifiée | Fuseau horaire, fenêtres d'exploitation et permissions | Politique finale et transitions observées |
Toute commutation électrique et tout test de fonction de protection nécessitent un personnel qualifié suivant la procédure applicable. Ne modifiez pas la protection du réseau pour accélérer une démonstration, contourner un verrouillage ou provoquer un défaut de batterie. Lorsqu'une fonction ne peut pas être testée immédiatement, maintenez-la explicitement en suspens plutôt que de déclarer la mise en service entièrement acceptée.
Préserver la différence entre retour arrière logiciel et récupération sûre
Un fichier de firmware antérieur ne prouve pas que la rétrogradation est prise en charge. Les formats de paramètres, les révisions matérielles ou les restrictions du fabricant peuvent l'empêcher. Obtenez une voie de récupération prise en charge avant le changement. Cette voie peut impliquer un service local ou un contrôleur de remplacement plutôt qu'une rétrogradation logicielle.
Pour un projet qui utilise un système de batterie résidentiel pour les charges essentielles, prévoyez une alimentation alternative approuvée si nécessaire. Le temps de récupération ne doit pas être estimé à partir d'une autre installation. Confirmez la disponibilité du personnel et l'accès au support pour la fenêtre de service convenue.
Maintenir une référence de version fiable pour les équipes de service
Les recommandations de gestion de configuration NIST SP 800-128, publiées en 2011 et mises à jour en 2019, expliquent la gestion et la surveillance des configurations tout en soutenant les fonctions métier requises. Il s'agit de recommandations générales sur les systèmes d'information, et non d'une nouvelle exigence de certification pour onduleurs. Son principe de référence est utile lorsqu'il est appliqué avec soin aux enregistrements d'un projet de stockage.
Après la mise à jour, enregistrez les versions réellement installées, les paramètres finaux approuvés et les résultats des tests. Consignez toute différence par rapport à la référence précédente, les problèmes non résolus et la personne ayant accepté le changement. Recueillez des preuves avant et après la mise à jour afin qu'un technicien ultérieur puisse distinguer un changement lié à la version d'un problème de site sans rapport.
Pour les parcs d'installations, vérifiez les groupes de matériel et de configuration concernés avant d'étendre un déploiement. La réussite sur un modèle ne qualifie pas chaque unité du parc. Un déploiement progressif approuvé par le fabricant peut réduire l'incertitude, mais il ne doit pas retarder une correction obligatoire au-delà de la réponse autorisée.
Clôturer le changement sur la fonction, et non sur l'état d'installation
L'enregistrement du changement doit répondre aux questions suivantes : pourquoi la mise à jour était-elle nécessaire, qu'est-ce qui a changé, quelles fonctions ont été retestées et qu'est-ce qui reste en suspens ? Lorsque ces réponses sont claires, le distributeur peut soutenir l'installation sans dépendre de la mémoire ou de captures d'écran prises avant la mise à niveau. Le point d'acceptation final est le service restauré et vérifié, et non un nouveau numéro de version.