Brevet FR3067149A1 — publié le 20181207

Mise à jour hiérarchisée de logiciels d'équipements d'un réseau de distribution électrique La présente invention concerne le contrôle-commande d'équipements mis en oeuvre dans le contexte des réseaux électriques intelligents de type « smartgrids ». L'invention concerne plus particulièrement un procédé relatif aux opérations de maintenance (« O&M ») de ces équipements et plus précisément aux mécanismes de gestion et de mise à jour de versions de logiciels, tel que notamment les logiciels métiers (ou « firmware ») dans tout ou partie des équipements distribués d'un réseau. On entend de façon générale par « mise à jour de logiciel » le fait de mettre à jour une version de logiciel métier auprès d'un équipement, ou encore simplement d'installer un logiciel dans un nouvel équipement, ou encore de mettre à jour un ou plusieurs fichiers qu'utilise un tel logiciel. Il peut s'agir de mise à jour de fonctions d'automatisation de ces équipements, ou encore d'autres fonctions, telles que des fonctions de télécommunications ou de cyber-sécurité. La mise à jour des firmware et autres fichiers dans un réseau de contrôle-commande d'équipements d'un réseau électrique se déroule sous le contrôle d'un noeud central racine qui peut être par exemple dans le contexte smartgrids un noeud nommé « Smartgrid Device Management System » (portant la référence SDMS dans les dessins annexés). Ce noeud gère entre autres les actions de mise à jour du réseau de la couche « opération » du modèle standard « smartgrid » défini par l'organisme de normalisation IEC (pour « International Electrotechnical Commission »). Ainsi, il est fait transiter sur l'ensemble des branches du réseau une quantité importante de données. Cette quantité de données est d'autant plus importante que l'équipement dont le logiciel à mettre à jour est proche du noeud racine. Par conséquent, certains noeuds du réseau proches du noeud racine et/ou le noeud racine lui- même peuvent être saturés par des demandes de mises à jour de logiciels d'équipements en aval dans le réseau. Par ailleurs, aujourd'hui, de nombreux équipements sont mis à jour manuellement selon un 30 processus complexe d'ordonnancement. 3067149 2 La présente invention vient améliorer cette situation. Elle propose à cet effet un procédé mis en oeuvre par des moyens informatiques de mise jour de logiciels destinés à être exécutés par des équipements d'un réseau de distribution 5 électrique. Chaque équipement forme un noeud d'un réseau de contrôle-commande communiquant avec d'autres noeuds de ce réseau de contrôle-commande. Les noeuds du réseau de contrôle-commande ont des identifiants respectifs. Le procédé comporte en particulier les étapes mises en oeuvre par un noeud courant : - obtenir des premières données de l'identifiant d'au moins un noeud secondaire pour 10 lequel le noeud courant est configuré pour autoriser une mise à jour de logiciel, et - sur réception d'une requête de mise à jour de logiciel pour un noeud secondaire, utiliser lesdites premières données pour une mise à jour de logiciel au moins pour le noeud secondaire identifié dans lesdites premières données. 15 Ainsi, la présente invention propose une hiérarchie prédéfinie (initialement en fonction de la topologie du réseau ou dynamiquement en fonction de nouvelles installations de matériel) dans les mises à jour des logiciels à effectuer pour chaque équipement du réseau de distribution électrique. Une telle réalisation permet avantageusement de distribuer le rôle des différents noeuds du 20 réseau pour propager ces mises à jour. Ainsi, il est possible de définir également des noeuds référents du réseau, susceptibles de diffuser ces mises à jour vers des noeuds secondaires. On comprendra alors que dans une telle réalisation les étapes suivantes peuvent être mises en oeuvre par un noeud courant qui se définit cette fois en tant que noeud secondaire de tels noeuds référents : 25 - obtenir des deuxièmes données comprenant au moins un identifiant de noeud référent du noeud courant, et, pour une mise à jour de logiciel du noeud courant: - lire lesdites deuxièmes données pour identifier au moins un noeud référent, et 3067149 3 - élaborer une requête de mise à jour du logiciel du noeud courant, ladite requête étant destinée au noeud référent identifié et comportant l'identifiant du noeud courant. Ainsi, selon la définition générale de l'invention exposée ci-avant, un noeud référent peut autoriser la mise à jour pour un ou plusieurs noeuds secondaires. Dans ce mode de 5 réalisation particulier, inverse, un noeud secondaire peut avoir un ou plusieurs noeuds référents déclarés dans les deuxièmes données précitées, et ce en vue de résoudre le même problème présenté en introduction ci-avant. Ce mode de réalisation, inverse, est avantageux en tant que tel et peut faire l'objet d'une protection séparée. 10 Avantageusement, il est possible d'utiliser des identifiants présents dans les requêtes de mise à jour pour autoriser ou non un transfert des données de mise à jour pour un noeud secondaire, et le procédé peut comporter à cet effet les étapes suivantes, mises en oeuvre par un noeud courant : 15 * sur réception d'une requête de mise à jour de logiciel pour un noeud donné, ladite requête comportant l'identifiant du noeud donné, - déterminer si l'identifiant du noeud donné est compris parmi lesdites premières données, et - le cas échéant, autoriser une mise à jour de logiciel pour le noeud donné, ou 20 refuser sinon ladite mise à jour. Dans une forme de réalisation, chaque noeud stocke à la fois les premières et secondes données. Une telle réalisation permet de faire en sorte que chaque noeud du réseau soit autonome tant pour la transmission des données de mise à jour vers des noeuds secondaires, 25 que pour la réception de ces données de mise à jour auprès d'un noeud référent. Dans une réalisation, les premières données comportent une liste d'identifiants de noeuds secondaires. Ainsi, chaque noeud peut diffuser les mises à jour vers plusieurs noeuds secondaires. 3067149 4 Réversiblement, dans une réalisation, les deuxièmes données comportent une liste d'identifiants de noeuds référents. Dans une telle réalisation, chaque noeud secondaire peut avoir plusieurs noeuds référents, avantageusement afin d'obtenir simultanément différentes 5 données issues de différents noeuds référents, ou encore afin de se reporter à un autre noeud référent en cas d'échec de réception des données d'un premier noeud référent. Dans une réalisation, au moins l'une des listes d'identifiants de noeuds secondaires et/ou référents est déclarée dans la norme IEC 61850 comme une instanciation multiple d'objets 10 de type « Data Objects ». Une telle réalisation permet d'homogénéiser la répartition des informations de noeuds référents et de noeuds secondaires auprès de toutes les entités du réseau, et ce de façon normalisée. En outre, la norme précitée IEC 61850 permet de définir en particulier une liste de noeuds, et ce possiblement grâce à l'instanciation multiple précitée de Data Objects. 15 Plus particulièrement, cette instanciation multiple peut être dans la classe de noeud logique « Logical Node LIFH », relative à la gestion du logiciel auprès d'un noeud courant, selon cette norme IEC 61850. 20 Dans une réalisation avantageuse, la liste d'identifiants de noeuds référents peut être ordonnée et, pour une mise à jour de logiciel d'un noeud courant, ce noeud courant : - lit lesdites deuxièmes données pour identifier au moins un premier noeud référent de la liste ordonnée, - élabore une première requête de mise à jour, destinée au premier noeud référent identifié, 25 et - après une temporisation, en cas de non réception de mise à jour, élabore une autre requête destinée au noeud référent suivant identifié dans la liste ordonnée, jusqu'à recevoir ladite mise à jour. 3067149 5 Une telle réalisation permet de définir plus finement la hiérarchie des noeuds dans le réseau, et notamment des noeuds référents de chaque noeud. Dans une réalisation, le procédé peut comporter en outre une étape préalable dans laquelle 5 une entité de gestion des noeuds du réseau de contrôle-commande détermine, pour chaque noeud, un ou plusieurs noeuds référents et/ou un ou plusieurs noeuds secondaires, selon une topologie prédéterminée du réseau de contrôle-commande. Avantageusement, une telle réalisation peut être mise en oeuvre par une entité de gestion du réseau, éventuellement par coopération en communiquant avec un noeud racine du réseau. 10 La présente invention vise aussi un système comportant au moins : - un premier équipement comportant un circuit informatique programmé pour exécuter les étapes du procédé ci-avant, en tant que noeud référent, et - un deuxième équipement comportant un circuit informatique programmé pour exécuter 15 les étapes du procédé en tant que noeud secondaire. On a illustré à titre d'exemple un tel circuit informatique de l'un ou l'autre de ces premier et deuxième équipements sur la figure 4. Ainsi, dans l'exemple illustré sur la figure 4, le circuit informatique CT comporte une interface de communication COM avec le réseau de contrôle-commande SMG, relié à un processeur PROC capable d'exécuter des opérations 20 correspondant aux étapes du procédé ci-avant. À cet effet, le processeur PROC coopère avec une mémoire MEM stockant notamment des instructions d'un programme informatique au sens de l'invention, ainsi que des données telles que celles des listes de noeuds secondaires et/ou référents. Le processeur PROC est relié en outre à une interface INT pour piloter une mise à jour du logiciel (le logiciel métier notamment) qu'exécute un 25 module de commande de l'équipement CEQ, pour opérer le fonctionnement de l'équipement. Le système peut comporter en outre une entité de gestion des noeuds du réseau de contrôle-commande, cette entité comportant un circuit informatique programmé pour exécuter 3067149 6 notamment l'étape préalable de détermination des première et deuxième données en fonction de la topologie du réseau. La présente invention vise aussi un programme informatique comportant des instructions 5 (éventuellement réparties entre les différents équipements et entité précités) pour la mise en oeuvre du procédé, lorsque ce programme est exécuté par un processeur. La présente invention vise aussi un équipement d'un réseau de distribution électrique, comportant un circuit informatique programmé pour exécuter les étapes du 10 procédé en tant que noeud référent. Elle vise aussi un équipement d'un réseau de distribution électrique, comportant un circuit informatique programmé pour exécuter les étapes du procédé en tant que noeud secondaire. D'autres avantages et caractéristiques de l'invention apparaîtront à la lecture de la 15 description détaillée de modes de réalisation présentés ci-après à titre d'exemples non limitatifs, et à l'examen des dessins annexés sur lesquels : - la figure 1 illustre schématiquement un système pour la mise en oeuvre de l'invention, - la figure 2 illustre schématiquement les étapes d'un procédé au sens de l'invention, selon un exemple de réalisation, 20 - la figure 3 est un exemple de diagramme de séquence pour une mise à jour de logiciel selon le procédé de la figure 2, - la figure 4 représente très schématiquement un exemple de structure type d'un équipement pour la mise en oeuvre de l'invention (en tant que noeud référent, ou en tant que noeud secondaire, ou encore en tant qu'entité de gestion des opérations de maintenance des 25 équipements du réseau et notamment des mises à jour de ces équipements), - la figure 5 illustre schématiquement le système de la figure 1 dans une première étape, initiale, du procédé, 3067149 7 - la figure 6 illustre schématiquement le système de la figure 1 dans une deuxième étape, courante, du procédé. On a représenté sur la figure 1 un ensemble d'équipements EQ1, EQi, EQj d'un réseau de 5 distribution d'électricité, tels que par exemple un poste transformateur HTA/BT, un ou plusieurs poteaux avec éventuellement des routeurs, jusqu'à des noeuds feuilles du réseau (non représentés). Ces équipements sont dits « intelligents » et en particulier comportent des moyens de communication entre équipements, au sein d'un réseau de télécommunication de type « smartgrid » SMG. Ainsi, chacun de ces équipements EQ1, 10 EQi, EQj peut former un noeud SDMS, Ni, Nj, etc. du réseau SMG. Par exemple, la référence SDMS de la figure 1 peut désigner un noeud central racine nommé « Smartgrid Device Management System », qui peut alors recevoir les listes précitées de noeuds secondaires et de noeuds référents, et ce pour chaque noeud Ni, Nj, etc., 15 en aval du réseau. En référence maintenant à la figure 5 illustrant cette situation, ces listes Li(R), Li(S) ; Lj(R), Lj(S) ; etc. de noeuds référents et de noeuds secondaires sont initialement et/ou dynamiquement établies, par exemple en fonction d'une topologie du réseau. L'entité en charge de définir ces listes peut être à titre d'exemple non limitatif une entité de gestion du réseau FUMS (pour « Firmware Update Management System ») 20 notamment en charge des mises à jour de logiciels (notamment les logiciels métiers ou « firmware ») qu'exploitent les équipements. Cette entité FUMS peut coopérer avec le noeud SDMS à cette fin. Le noeud SDMS transmet alors à chaque noeud Ni un couple de listes de noeuds référents Li(R) et de noeuds secondaires Li(S), que chaque noeud peut stocker alors en mémoire 25 MEM. Il convient de noter qu'un noeud feuille complètement en aval du réseau SMG peut n'avoir que des noeuds référents et sa liste de noeuds secondaires peut se réduire à un ensemble vide ou ce noeud peut simplement ne pas avoir de liste de noeuds secondaires. En référence maintenant à la figure 6, le noeud SDMS, sur réception d'une requête de mise à jour des logiciels des équipements, transmet à ses noeuds secondaires (R1, R3 dans l'exemple de la figure 6) une autorisation de mettre à jour leur logiciel (via le noeud SDMS par exemple). Ensuite, par exemple le noeud R1 est référent pour des noeuds secondaires Si en aval et leur transmet une autorisation de mise à jour à leur tour. De même, un noeud Si 3067149 8 peut être un noeud référent R2 pour des noeuds secondaires S2 subséquents, et ainsi de suite. Il convient de relever, comme illustré sur la figure 6, qu'un noeud secondaire (Si) peut avoir plusieurs noeuds référents R1, R3. Une telle réalisation peut être avantageuse pour télécharger simultanément différentes parties des mises à jour à effectuer, ces 5 différentes parties étant issues de différents noeuds référents R1, R3 afin de soulager la charge de chaque noeud référent. Par ailleurs, il peut être avantageux de prévoir une liste ordonnée de noeuds référents pour attendre d'un premier noeud les données de mise à jour, puis après une temporisation 10 attendre ces données d'un second noeud dans la liste ces données, si elles n'ont pas été fournies par le premier noeud de la liste, et ainsi de suite. Cette réalisation est illustrée sur la figure 2, laquelle est maintenant commentée ci-après. Une fois la topologie du réseau définie lors d'une première étape S10, il peut être défini à l'étape S1 1 les listes de noeuds référents Li(R) et de noeuds secondaires Li(S). Ces listes 15 sont communiquées à l'étape 512 aux différents noeuds du réseau smartgrid pour être stockées à l'étape 513 par chacun des noeuds, dans un exemple de réalisation. Il convient de noter qu'en variante ces listes de noeuds peuvent être stockées par exemple par le noeud racine SMDS ou par l'entité de gestion des mises à jour FUMS. 20 Ensuite, lors d'une étape courante 514, un noeud courant du réseau reçoit une requête de mise à jour (cette requête comportant typiquement un identifiant d'un noeud N du réseau). Cette requête peut être issue du noeud racine SDMS, par exemple, pour une mise à jour ciblée d'un noeud précis N du réseau, et comporte alors l'identifiant de ce noeud N à cet effet. En variante, cette requête peut être émise directement par ce noeud N, suite à 25 l'installation d'un nouveau matériel connecté à ce noeud N par exemple. La liste des noeuds secondaires L(S) du noeud courant comporte typiquement la liste des identifiants de ces noeuds secondaires, ce qui permet au noeud courant de comparer à l'étape 515 l'identifiant présent dans la requête à la liste des identifiants de noeuds secondaires. À 30 l'issue de cette comparaison, si le noeud courant ne retrouve pas l'identifiant du noeud N dans la liste, le noeud courant rejette la requête à l'étape 516. Sinon, il transmet à l'étape 517 les données de mise à jour nécessaires du logiciel du noeud N. 3067149 9 En complément ou en variante (typiquement dans le cas d'un noeud feuille en aval du réseau), un noeud courant peut, à l'étape S30, recevoir un ordre de mise à jour issu par exemple de l'entité FUMS (via le noeud racine SDMS par exemple). À l'étape S31, ce noeud courant peut consulter la liste L(R) de ses noeuds référents et plus particulièrement leurs 5 identifiants respectifs pour leur adresser des requêtes des données de mise à jour. Ainsi, à l'étape S32, l'identifiant du premier noeud référent NR1 de la liste L(R) est utilisé pour établir la première requête des données de mise à jour. Si ces données ne sont pas reçues à l'étape S33 après une temporisation S35, alors la liste est consultée à nouveau pour adresser la requête au noeud suivant de la liste à l'étape S36. Si les données ne sont 10 toujours pas reçues après épuisement des identifiants de la liste, le noeud courant peut adresser à nouveau une requête au premier noeud NR1 et réitérer les étapes S32, S33, S35 et S36, jusqu'à recevoir les données de mise à jour à l'étape S34. Ainsi, il est proposé dans cette réalisation de définir dans le réseau un sous-ensemble de 15 noeuds « référents » dans lesquels sont stockés ou téléchargés dans un premier temps un logiciel (ou firmware) « à jour ». Ces noeuds référents (Noeuds R) gèrent dans un deuxième temps la diffusion des mises à jour vers les noeuds secondaires (Noeuds S) par l'intermédiaire de protocoles qui peuvent respecter la norme IEC-61850, comme exposé ci-après. 20 Il est donc proposé une évolution du modèle de données de chaque équipement comprenant deux nouveaux paramètres définis par des variables de type « data object » selon la norme IEC-61850 : - Une liste de noeuds référents aptes à mettre à jour un noeud courant nécessitant une 25 mise à jour de logiciel, et - Une liste de noeuds secondaires pour lesquels un équipement courant peut être un noeud référent configurés pour autoriser la mise à jour pour ces noeuds secondaires. Chaque équipement stocke en mémoire (ou peut accéder à une mémoire distante stockant) une liste entretenue de noeuds référents et de noeuds secondaires. Un noeud secondaire peut- 30 être mis à jour par plusieurs noeuds référents afin d'apporter une résilience au système. On peut ainsi définir implicitement (selon l'ordre des noeuds référents dans la liste) ou 3067149 10 explicitement par d'autres attributs de noeuds une priorité de noeuds référents pour la mise à jour de noeuds secondaires. Ces noeuds prioritaires peuvent par exemple bénéficier avantageusement d'un niveau de cyber-sécurité (anti-intrusion) plus élevé que les autres noeuds de la liste. 5 Plus précisément, la norme IEC 61850-90-16 (Partie 90-16 - « Using IEC 61850 for System Management purposes ») peut évoluer pour proposer deux nouvelles variables décrivant les paramètres définissant respectivement les noeuds référents et les noeuds secondaires. Le nombre maximum de noeuds secondaires ou référents peut être configuré dans le 10 modèle de données de l'équipement de manière statique ou dynamique. Comme le précise la norme IEC 61850-7-2 (Edition 2.1 - « Conditions for presence elements »), les objets dits « Data Objects » d'une classe de noeud logique se voient attribuer une conditionnalité (colonne M/O/C comme présenté dans la table ci-après). Celle-ci permet également de définir la possibilité d'avoir une multiplicité d'instances de 15 ces « data objects » (Mmulti, Omulti). Les sigles M/O/C désignent respectivement Mandatory (obligatoire), Optionnal (optionnel) et Conditionnal (conditionnel). Ici, il est choisi à titre d'exemple une conditionnalité de type « optionnelle » et « multiple » (Omulti), mais d'autres réalisations sont possibles. Concrètement cette conditionnalité donne la possibilité d'instancier un nombre supérieur ou égale à zéro de ces « data 20 obj ects ». Plus particulièrement, dans la classe de noeud logique relative à la gestion du logiciel métier auprès d'un équipement donné (équipement intelligent dans le contexte d'un réseau smartgrid et appelé IED pour « Intelligent Electronic Device »), cette classe étant désignée « Logical Node LIFH » selon IEC 61850-90-16 (avec IFH pour « IED Firmware 25 Handling »), on peut définir : - Une nouvelle variable DataObject nommée "FWUpdRef" (pour « Firmware Update Reference Nodes ») de conditionnalité « optionnelle » "OMulti" (définie par un réglage « Integer Status Setting ») qui donne les identifiants des noeuds référents pour les mises à jour du logiciel de l'équipement donné IED, précité ; et 30 - Une nouvelle variable DataObject nommée "FWUpdSec" (pour « Firmware Update Secondary Nodes ») de conditionnalité « optionnelle » "OMulti" (définie par un 3067149 11 réglage « Integer Status Setting ») et qui donne les identifiants des noeuds secondaires pour leurs mises à jour en transférant les données de mise à jour via l'équipement donné IED, précité. 5 La table de déclaration de ces variables peut alors être comme suit : 1Data object name Common data class Explanation T M/0/C FWUpdRef VSG Referent Nodes list for IED I °Mufti 1 F FWUpdSec VSG Secondary Nodes list for IED 10Multi .1. t La liste d'objets peut alors être définie en se basant sur le type (Common Data Class) « Visible String Setting » défini dans IEC 61850-7-3 dont l'abréviation est « VSG ». Chaque noeud référent peut ainsi autoriser et procéder à la mise à jour du logiciel d'un 10 noeud secondaire si ce noeud secondaire est dans sa liste. Chaque noeud secondaire peut, pour la mise à jour de son logiciel, s'adresser à un noeud référent autorisé s'il est dans sa liste de noeuds référents. La figure 3 illustre une réalisation possible d'une séquence de mise à jour des logiciels de 15 type firmware. A l'étape S20, une entité de gestion des mises à jour de firmware des équipements du réseau FUMS (pour Firmware Update Management System) commence par notifier qu'une nouvelle version est disponible pour un certains équipements du réseau par exemple (ou certains modèles d'équipement IED typiquement). Une entité de gestion des équipements 20 de contrôle-commande « smartgrid », référencée SDMS, déclenche à l'étape S21, consécutive à l'étape S20, le processus de déploiement de la mise à jour vers un (ou plusieurs) équipement(s) destinataire(s) référent(s) R. Après récupération de la nouvelle version (et accusé de réception de cette nouvelle version à l'étape S22), chaque noeud référent R notifie à son tour (étape S23) ses noeuds définis comme secondaires S de la 25 disponibilité de cette mise à jour. Ces noeuds secondaires S sont alors en mesure de demander (étape S24) et de récupérer (S25) auprès du noeud référent R cette nouvelle version logicielle afin de mettre à jour le firmware. Ensuite, chaque équipement ayant 3067149 12 effectué cette mise à jour peut notifier à l'étape S26 la fin de cette mise à jour à l'entité SDMS pour y enregistrer ce changement. Il convient de noter qu'une variante peut consister à prévoir que les noeuds secondaires 5 interrogent à un intervalle de temps défini leur(s) noeud(s) référent(s) pour vérifier si une nouvelle mise à jour est disponible. De manière générale, la présente invention ne se limite pas aux formes de réalisation décrites ci-avant à titre d'exemple ; elle s'étend à d'autres variantes. 10 Par exemple, on a présenté ci-avant la situation dans laquelle un noeud courant peut disposer à la fois d'une liste de noeuds secondaires et d'une liste de noeuds référents. Toutefois, dans une réalisation moins sophistiquée, il peut n'être prévu qu'une liste de noeud secondaires, chaque noeud courant propageant ainsi les données de mise à jour aux noeuds secondaires qui lui sont en aval. 15 REVENDICATIONS1. Procédé mis en oeuvre par des moyens informatiques de mise jour de logiciels destinés à être exécutés par des équipements d'un réseau de distribution électrique, chaque équipement formant un noeud d'un réseau de contrôle-commande communiquant avec d'autres noeuds du réseau de contrôle-commande, les noeuds du réseau de contrôle-commande ayant des identifiants respectifs, le procédé comportant les étapes mises en oeuvre par un noeud courant : - obtenir des premières données de l'identifiant d'au moins un noeud secondaire pour lequel le noeud courant est configuré pour autoriser une mise à jour de logiciel, et - sur réception d'une requête de mise à jour de logiciel pour un noeud secondaire, utiliser lesdites premières données pour une mise à jour de logiciel au moins pour le noeud secondaire identifié dans lesdites premières données. 2. Procédé selon la revendication 1, comportant les étapes mises en oeuvre par un noeud courant : sur réception d'une requête de mise à jour de logiciel pour un noeud donné, ladite requête comportant l'identifiant du noeud donné, - déterminer si l'identifiant du noeud donné est compris parmi lesdites premières données, et - le cas échéant, autoriser une mise à jour de logiciel pour le noeud donné, ou refuser sinon ladite mise à jour. 3. Procédé mis en oeuvre par des moyens informatiques de mise jour de logiciels destinés à être exécutés par des équipements d'un réseau de distribution électrique, chaque équipement formant un noeud d'un réseau de contrôle-commande communiquant avec d'autres noeuds du réseau de contrôle-commande, les noeuds du réseau de contrôle-commande ayant des identifiants respectifs, le procédé comportant les étapes mises en oeuvre par un noeud courant : 3067149 14 - obtenir des deuxièmes données comprenant au moins un identifiant de noeud référent du noeud courant, et, pour une mise à jour de logiciel du noeud courant: - lire lesdites deuxièmes données pour identifier au moins un noeud référent, et 5 - élaborer une requête de mise à jour du logiciel du noeud courant, ladite requête étant destinée au noeud référent identifié et comportant l'identifiant du noeud courant. 4. Procédé selon la revendication 3 prise en combinaison avec l'une des revendications 1 et 2, dans lequel chaque noeud stocke les premières et secondes données. 10 5. Procédé selon l'une des revendications 1, 2 et 4, dans lequel les premières données comportent une liste d'identifiants de noeuds secondaires. 6. Procédé selon l'une des revendications 3 à 5, dans lequel les deuxièmes données 15 comportent une liste d'identifiants de noeuds référents. 7. Procédé selon l'une des revendications 5 et 6, dans lequel au moins l'une des listes d'identifiants de noeuds secondaires et/ou référents est déclarée dans la norme IEC 61850 comme une instanciation multiple d'objets de type « Data Objects ». 20 8. Procédé selon la revendication 7, dans lequel ladite instanciation multiple est dans la classe de noeud logique « Logical Node LIFH », relative à la gestion du logiciel auprès d'un noeud courant, selon la norme IEC 61850. 25 9. Procédé selon l'une des revendications 6 à 8, dans lequel la liste d'identifiants de noeuds référents est ordonnée et, pour une mise à jour de logiciel d'un noeud courant, ce noeud courant : 3067149 15 - lit lesdites deuxièmes données pour identifier au moins un premier noeud référent de la liste ordonnée, - élabore une première requête de mise à jour, destinée au premier noeud référent identifié, et 5 - après une temporisation, en cas de non réception de mise à jour, élabore une autre requête destinée au noeud référent suivant identifié dans la liste ordonnée, jusqu'à recevoir ladite mise à jour. 10. Procédé selon l'une des revendications précédentes, comportant en outre une étape 10 préalable dans laquelle une entité de gestion des noeuds du réseau de contrôle-commande détermine, pour chaque noeud, un ou plusieurs noeuds référents et/ou un ou plusieurs noeuds secondaires, selon une topologie prédéterminée du réseau de contrôle-commande. 11. Système comportant au moins : 15 - un premier équipement comportant un circuit informatique programmé pour exécuter les étapes du procédé selon l'une des revendications 1, 2, 4 à 9, en tant que noeud référent, et - un deuxième équipement comportant un circuit informatique programmé pour exécuter les étapes du procédé selon la revendication 3 en tant que noeud secondaire. 20 12. Système selon la revendication 11, comportant en outre une entité de gestion des noeuds du réseau de contrôle-commande, ladite entité comportant un circuit informatique programmé pour exécuter les étapes du procédé selon la revendication 10. 13. Programme informatique comportant des instructions pour la mise en oeuvre du 25 procédé selon l'une des revendications 1 à 10, lorsque ce programme est exécuté par un processeur. 3067149 16 14. Equipement d'un réseau de distribution électrique, comportant un circuit informatique programmé pour exécuter les étapes du procédé selon l'une des revendications 1, 2, 4 à 9, en tant que noeud référent. 5 15. Equipement d'un réseau de distribution électrique, comportant un circuit informatique programmé pour exécuter les étapes du procédé selon la revendication 3 en tant que noeud secondaire.