Brevet FR3164818A1 — publié le 20260123

L’invention se rapporte à un dispositif électronique de mesure de consommation d’une ressource (IPMx) comprenant : un processeur (P) et une mémoire (M) ; un modem (MIG), pour transmettre et recevoir des données par l’intermédiaire d’au moins un media de communication (CPL, RF) à l’aide d’un standard de communication, utilisé par un réseau de communication d’un fournisseur de la ressource auquel le dispositif électronique de mesure de consommation de la ressource (IPMx) est connecté ; un module de gestion (OMFCV) de fonctions virtualisées de communication (FCV), ledit module de gestion (OMFCV) étant configuré pour charger, à partir de la mémoire (M), au moins une fonction virtualisée de communication (FCV) à exécuter par le modem (MIG), ladite au moins une fonction virtualisée de communication (FCV) ayant été préalablement transmise et/ou paramétrée, à l’aide d’un fichier dédié (FFCV), provenant d’un contrôleur (CONT) connecté au dispositif électronique de mesure de consommation de la ressource (IPMx) par l’intermédiaire du réseau de communication. Figure 1 dispositif électronique de mesure de consommation d’une ressource, procédé, système et programme correspondant Domaine La présente invention porte sur le transfert et la gestion de versions de logiciels de dispositif électronique de mesure de consommation d’une ressource en lien avec un sous-réseau de communication par courants porteurs en ligne et/ou un réseau de communication secondaire. L’invention porte plus particulièrement sur la mise en œuvre d’un dispositif électronique de mesure de consommation d’une ressource et d’un système associé dans lequel des fonctions de communication peuvent être mises en œuvre de manière évolutive. Art antérieur La technologie des compteurs communicants et les infrastructures de télécommunications associées dites « AMI » (de l’anglais pour « Advanced Metering Infrastructure ») permet la collecte automatisée des données de consommation, de diagnostic et d'état des compteurs, comme ceux liés à l'électricité, au gaz et à l'eau. Elle permet d'économiser des coûts en évitant les relevés manuels périodiques mais aussi de suivre et facturer la consommation (ou la production, pour les compteurs d’électricité) réelle avec une granularité typiquement journalière. Un autre aspect propre à certaines infrastructures AMI est de pouvoir mettre en œuvre des actions à distance permettant par exemple des mises en service à distance ou l’ajustement du calendrier tarifaire du contrat souscrit. Ainsi les infrastructures AMI s’appuient sur une communication bidirectionnelle entre un collecteur de données (par ex. un nœud racine de réseau ou un routeur cellulaire) et plusieurs compteurs intelligents. Ces derniers permettent potentiellement une connectivité bidirectionnelle entre le lieu de consommation (ou de production, pour l’énergie électrique) et l'entreprise (de services publics) chargée de l’exploitation de ces compteurs. Dans le contexte de l'approvisionnement électrique, l’infrastructure AMI est l’un des constituants du réseau électrique intelligent et contribue à l'efficacité, la fiabilité et la stabilité du système électrique. Dans les réseaux d'alimentation électrique implémentant la technologie AMM (de l’anglais pour « Advanced Meter Management »), des communications sont établies entre les compteurs électriques intelligents (« smart meters » en anglais) et un dispositif concentrateur de données, qui embarque souvent un rôle de gestionnaire de réseau télécom sous le nom de nœud de base, contrôleur ou coordinateur, comme dans les spécifications PRIME (de l’anglais pour « PoweRline Intelligent Metering Evolution ») ou G3-PLC. Les échanges entre les compteurs et le concentrateur de données s’appuient des communications par courants porteurs en ligne (« PowerLine Communications » en anglais) (par exemple CPL G3), hybride (CPL et radio, par exemple G3-Hybrid) ou radio en réseau maillé « mesh » (WiSUN, par exemple). Le dispositif concentrateur est la racine du réseau de communication ayant une topologie logique en forme d'arbre pour étendre la portée des communications. Ainsi, un réseau maillé est mis en œuvre. Des compteurs intelligents servent de relais pour d'autres compteurs intelligents du réseau lorsqu'ils ne peuvent pas recevoir directement les informations du contrôleur. Le document "Bluebook: COSEM Interface Classes and OBIS Object Identification System" décrit une méthode en deux phases pour déployer une nouvelle version de logiciel par blocs auprès des compteurs intelligents à partir du contrôleur : une première phase sans retransmission, et une seconde phase ultérieure pour transférer les blocs manquants. Or, avec l'essor des réseaux de distribution de ressources intelligents, un trafic de communication important est apparu, comprenant de nombreux appareils ajoutés aux infrastructures électriques, gazières, d'eau et d'autres consommables. Le trafic réseau inclut des paquets de données transmis et reçus par les composants selon divers protocoles, sur des réseaux câblés (ex: CPL) et non câblés (ex: RF). Le nombre important de compteurs intelligents dans certaines zones géographiques (on parle de « réseaux denses »), couplé à un usage plus accru de leur fonctionnalité (collectes plus fréquentes, multiplication de la réalisation d’actions à distance, etc.) a entrainé un certain engorgement du réseau de communication, notamment du réseau CPL, entrainant des difficultés croissantes pour effectuer les mises à jour nécessaires des micrologiciels (« firmware » en anglais) des compteurs intelligents. Pour un compteur d’électricité, le micrologiciel couvre à la fois le logiciel fonctionnel du compteur (fonctions métier) et le logiciel de la pile protocolaire CPL (fonctions télécom), ce dernier étant typiquement exécuté dans un microcontrôleur associé à un System-On-Chip (SOC) s’appuyant sur un composant de type DSP pour les couches les plus basses de la pile protocolaire. La mise à jour d’un micrologiciel consiste à transmettre un fichier binaire aux compteurs intelligents à mettre à jour. Cette mise à jour s’appuie typiquement sur le mécanisme « Image Transfer », propre au protocole métier DLMS/COSEM, qui permet de transmettre un fichier binaire d’une longueur de « x » octets par la transmission de « n » blocs de « x/n » octets. Selon le document "Bluebook: COSEM Interface Classes and OBIS Object Identification System", plusieurs tentatives de transmission sont possibles voire nécessaires (en cas de congestion ou de perturbation du réseau CPL, hybride ou radio) en cas d’échec de transmission d’un bloc. Le transfert n’est complet qu’une fois les « n » blocs correctement reçus par le compteur à mettre à jour. Une fois le transfert du fichier binaire complet, le compteur à mettre à jour doit procéder à la vérification de celui-ci avant de mettre en œuvre les actions dans son environnement d’exécution, permettant de remplacer l’ancien micrologiciel avec le nouveau micrologiciel (issu du fichier binaire nouvellement reçu). Ce mode de mise à jour présente plusieurs inconvénients : - la congestion ou les perturbations électromagnétiques du réseau CPL, hybride ou radio peuvent créer de nombreux échecs de communication et amener à un nombre important de tentatives de retransmission d’un ou plusieurs blocs en échec pour un ou plusieurs compteurs ; ces nouvelles tentatives créent à leur tour plus de congestion, renforçant les dysfonctionnements sur le réseau ; - la détection de la corruption d’un seul bloc peut amener à un échec complet du processus de transfert qui devra alors être répété ; dans le cas d’un réseau maillé (c’est-à-dire que la connectivité avec certains compteurs dépend de la connectivité de ces compteurs avec d’autre compteurs), la détection d’un échec de mise à jour d’un compteur donné peut, dans certains cas, amener l’ensemble des compteurs CPL, hybrides ou radio du réseau maillé (on parle d’une grappe de compteurs) à rebasculer sur l’ancien micrologiciel jusqu’à ce que ce compteur ait réussi à effectuer sa mise à jour. - la mise à jour d’un mécanisme mineur de la pile protocolaire CPL, hybride ou radio amène systématiquement à la mise à jour de tout le micrologiciel de tous les compteurs d’une grappe. Par ailleurs, l’optimisation des piles protocolaires est un problème de conception récurrent. De manière générale, chaque mécanisme composant une pile protocolaire donnée est conçu en prenant en compte les contraintes du canal de communication (connu par la théorie et les constats empiriques établis, à la suite des retours d’expérience résultant de l’exploitation d’infrastructures existantes) mais aussi du cas d’usage applicatif. La conception d’un mécanisme protocolaire donné constitue ainsi un compromis et ce mécanisme n’est pas (ou peu) adaptable en temps réel aux contraintes locales (au niveau de l’objet communicant CPL, hybride ou radio d’un réseau « IoT » local – « IoT » pour « Internet of Things » en anglais). Il est donc souhaitable de remédier à ces inconvénients et d'augmenter l'efficacité du transfert d'une nouvelle version logicielle aux compteurs des infrastructures AMI ou, plus généralement, à des objets communicants de réseaux de type « IoT ». L’invention vient améliorer la situation. Ainsi, l’invention porte sur un dispositif électronique de mesure de consommation d’une ressource comprenant : un processeur et une mémoire ; un modem, pour transmettre et recevoir des données par l’intermédiaire d’au moins un medium de communication à l’aide d’un standard de communication, utilisé par un réseau de communication d’un fournisseur de la ressource auquel le dispositif électronique de mesure de consommation de la ressource est connecté ; un module de gestion de fonctions virtualisées de communication, ledit module de gestion étant configuré pour charger, à partir de la mémoire, au moins une fonction virtualisée de communication à exécuter par le modem, ladite au moins une fonction virtualisée de communication ayant été préalablement transmise et/ou paramétrée, à l’aide d’un fichier dédié, provenant d’un contrôleur connecté au dispositif électronique de mesure de consommation de la ressource par l’intermédiaire du réseau de communication. Ainsi, il est possible de modifier le mode opératoire du dispositif électronique de mesure de consommation de ressource sans effectuer de modification importante de son architecture logicielle tout en préservant la bande passante du ou des réseaux de communications auxquels il est connecté. Selon une caractéristique particulière, le fichier dédié est reçu en lieu et place d’un fichier de mise à jour du micrologiciel du dispositif électronique de mesure de consommation de ressource. Selon une caractéristique particulière, le dispositif comprend au moins une base de données embarquée pour l’enregistrement, en provenance d’au moins une des fonctions virtualisées de communication, de données de suivi d’exécution. Ainsi, il est possible de suivre la mise en œuvre de fonctions de communication virtualisées de manière plus simple et efficace. Selon une caractéristique particulière, le dispositif comprend des moyens d’adaptation du fonctionnement d’au moins une des fonctions virtualisées de communication en fonction des données de suivi d’exécution de ladite au moins une base de données embarquée. Ainsi, il est possible de modifier le comportement des fonctions de communication virtualisées le cas échéant, sans avoir besoin de transférer un nouveau micrologiciel intégral. Selon une caractéristique particulière, le dispositif comprend au moins un réseau de neurones configuré pour fournir des paramètres d’adaptation d’au moins une des fonctions virtualisées de communication en fonction des données de suivi d’exécution de ladite au moins une base de données embarquée. Selon une caractéristique particulière, le fichier dédié comprend au moins un paramètre d’adaptation de fonctionnement d’au moins une des fonctions virtualisées de communication installée au sein du dispositif électronique de mesure de consommation de ressource. Ainsi, si des paramètres ne sont pas disponibles depuis le dispositif de mesure, il est possible de les lui transmettre depuis un contrôleur ou un dispositif de surveillance de fonctionnement, à nouveau sans nécessiter de mise à jour importante. Selon une caractéristique particulière, un premier medium de communication est de type courant porteur en ligne et en ce que qu’un deuxième medium de communication est de type radiofréquence et en ce que le modem est un modem hybride. Selon une caractéristique particulière, le dispositif électronique de mesure de consommation de la ressource est un compteur électrique intelligent. Selon un autre aspect, l’invention porte également sur un système de contrôle d’une pluralité de dispositifs de mesure de consommation d’une ressource. Selon l’invention, un tel système comprend : un réseau de communication ; la pluralité de dispositifs de mesure de consommation de la ressource, chaque dispositif de mesure de consommation de la ressource comprenant : un processeur et une mémoire ; un modem, pour transmettre et recevoir des données par l’intermédiaire d’au moins un medium de communication à l’aide d’un standard de communication, utilisé par un réseau de communication d’un fournisseur de la ressource auquel le dispositif électronique de mesure de consommation de la ressource est connecté ; un module de gestion d’au moins une fonction virtualisée de communication, le module de gestion étant apte à charger, à partir de la mémoire, au moins une fonction de communication à exécuter par le modem ; un contrôleur, connecté à la pluralité des dispositifs de mesure de consommation de la ressource par l’intermédiaire du réseau de communication, le contrôleur étant apte à transmettre, à toute ou partie de la pluralité de dispositifs de mesure de consommation de la ressource, une pluralité de fichiers de mise à jour de fonction de communication, la taille des fichiers de mise à jour de fonction étant réduite par rapport à la taille du micrologiciel du modem. Selon un autre aspect, l’invention se rapporte également à un dispositif électronique de type capteur et/ou actionneur appartenant à une infrastructure de communication de type internet des objets, comprenant : un processeur et une mémoire ; un modem, pour transmettre et recevoir des données par l’intermédiaire d’au moins un media de communication à l’aide d’un standard de communication utilisé par un réseau de communication de l’infrastructure de communication de type internet des objets auquel le dispositif électronique est connecté ; un module de gestion de fonctions virtualisées de communication, ledit module de gestion étant configuré pour charger, à partir de la mémoire, au moins une fonction virtualisée de communication à exécuter par le modem, ladite au moins une fonction virtualisée de communication ayant été préalablement transmise et/ou paramétrée, à l’aide d’un fichier dédié, provenant d’un contrôleur connecté au dispositif électronique par l’intermédiaire du réseau de communication. Selon une implémentation préférée, les différentes étapes des procédés selon la présente divulgation sont mises en œuvre par un ou plusieurs logiciels ou programmes d'ordinateur, comprenant des instructions logicielles destinées à être exécutées par un processeur de données d'un dispositif électronique de mesure de consommation de ressource ou, plus généralement, d’un objet communicant selon la présente technique et étant conçu pour commander l'exécution des différentes étapes des procédés, mis en œuvre au niveau du dispositif électronique de mesure de consommation d’une ressource ou de l’objet communicant, d’un serveur distant et/ou d’un système de gestion/surveillance de consommation de ressource ou d’objets communicants, dans le cadre d’une répartition des traitements à effectuer et déterminés par un code source scripté ou un code compilé. En conséquence, la présente technique vise aussi des programmes, susceptibles d’être exécutés par un ordinateur ou par un processeur de données, ces programmes comportant des instructions pour commander l'exécution des étapes des procédés tel que mentionnés ci-dessus. Un programme peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable. La présente technique vise aussi un support d'informations lisible par un processeur de données, et comportant des instructions d'un programme tel que mentionné ci-dessus. Le support d'informations peut être n'importe quelle entité ou terminal capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un support mobile (carte mémoire) ou un disque dur ou un SSD. D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon la présente technique peut être en particulier téléchargé sur un réseau de type Internet. Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé en question. Selon un mode de réalisation, la présente technique est mise en œuvre au moyen de composants logiciels et/ou matériels. Dans cette optique, le terme "module" peut correspondre dans ce document aussi bien à un composant logiciel, qu'à un composant matériel ou à un ensemble de composants matériels et logiciels. Un composant logiciel correspond à un ou plusieurs programmes d'ordinateur, un ou plusieurs sous-programmes d'un programme, ou de manière plus générale à tout élément d'un programme ou d'un logiciel apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Un tel composant logiciel est exécuté par un processeur de données d'une entité physique (terminal, serveur, passerelle, set-top-box, routeur, etc.) et est susceptible d'accéder aux ressources matérielles de cette entité physique (mémoires, supports d'enregistrement, bus de communication, cartes électroniques d'entrées/sorties, interfaces utilisateur, etc.). De la même manière, un composant matériel correspond à tout élément d'un ensemble matériel (ou hardware) apte à mettre en œuvre une fonction ou un ensemble de fonctions, selon ce qui est décrit ci-dessous pour le module concerné. Il peut s'agir d'un composant matériel programmable ou avec processeur intégré pour l'exécution de logiciel, par exemple un circuit intégré, une carte à puce, une carte à mémoire, une carte électronique pour l'exécution d'un micrologiciel (firmware), etc. Chaque composante du système précédemment décrit met bien entendu en œuvre ses propres modules logiciels. Les différents modes de réalisation mentionnés ci-dessus sont combinables entre eux pour la mise en œuvre de la présente technique. Brève description des figures D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles : FIG. 1 représente un dispositif électronique de mesure de consommation d’une ressource ; FIG. 2 représente les couches basses de la pile protocolaire G3-Hybrid (technologie hybride CPL et radio spécifiée dans la norme ITU-T G.9903) découpées en fonctions virtualisées de communication ; FIG. 3 représente une Architecture logicielle et matérielle d’un dispositif hébergeant une pile protocolaire découpée en fonctions virtualisées de communication ; FIG. 4 représente le chargement et le déchargement des fonctions virtualisées de communication dans un réseau maillé de dispositifs de mesure de consommation de ressources. Description d’un mode de réalisation La FIG. 1 illustre l’architecture d’un dispositif électronique de mesure de consommation d’une ressource IPMx, également appelé compteur ou compteur intelligent. Un tel dispositif comprenant : un processeur P et une mémoire M ; un modem MIG, pour transmettre et recevoir des données par l’intermédiaire, par exemple, de deux media de communication distincts (CPL, RF), l’un des deux media (ou les deux à la fois) pouvant être utilisé pour les communications avec les autres dispositifs communicants constitutifs du réseau de communication d’un fournisseur de la ressource auquel le dispositif électronique de mesure de consommation de la ressource IPMx est connecté ; un module de gestion OMFCV de fonctions virtualisées de communication FCV, ledit module de gestion OMFCV étant configuré pour charger, à partir de la mémoire M, au moins une fonction virtualisée de communication FCV à exécuter par le modem MIG, ladite au moins une fonction virtualisée de communication FCV ayant été préalablement transmise et/ou paramétrée, à l’aide d’un fichier dédié FFCV, provenant d’un contrôleur CONT connecté au dispositif électronique de mesure de consommation de la ressource IPMx par l’intermédiaire du premier réseau de communication. Le modem peut par exemple être un modem hybride selon le standard G3-Hybrid ou tout autre standard hybride, un modem CPL selon le standard G3-PLC, PRIME, un modem RF selon le standard WiSUN, ZigBee, Thread, LoRa. Le principe du réseau « hybride » n'est pas d'implémenter l'un ou l'autre des media CPL et RF, mais de permettre aux nœuds de sélectionner en temps réel le médium le plus adapté pour une transmission vers un des voisins du réseau (qui peuvent typiquement se compter en plusieurs dizaines). On notera que, selon le standard ITU-T G.9903 (G3-Hybrid): le medium choisi pour transmettre vers un nœud voisin peut varier au cours du temps ; le medium choisi pour un voisin est potentiellement différent de celui choisi pour un autre voisin ; certaines communications (de diffusion – broadcast – en particulier) sont transmises sur les deux media simultanément ; et en cas d'échec de communication vers un voisin avec le medium CPL, une retransmission peut être tenté avec le medium RF (et vice-versa). Ainsi, la divulgation propose une nouvelle approche de la modularité en mettant en œuvre une architecture réseau logicielle qui consiste à allouer dynamiquement des fonctions réseau virtualisées par un contrôleur CONT. Dès lors, le découpage d’une pile protocolaire CPL G3 ou G3-Hybrid, et en particulier des couches basses PHY-MAC-6LoWPAN définies par la G3-Alliance pour cette technologie, en plusieurs fonctions réseaux virtualisées confère un niveau de modularité important permettant de mettre à jour des mécanismes protocolaires, soit dans le cadre d’une mise à jour pérenne, ou ponctuellement, pour optimiser le fonctionnement d’un ou plusieurs mécanisme(s) protocolaire(s) pour faire face à des conditions particulières limitées dans le temps. Ces mises à jour sont effectuées facilement car la taille des fichiers binaires nécessaires à la transmission soit de la fonction virtualisée de communication FCV soit des paramètres de mise en œuvre de cette fonction, sont de taille réduite, ce qui résout les problématiques de congestion de ces réseaux de communication maillés. Ainsi, dans l’hypothèse d’une pile protocolaire adaptable de manière limitée, à travers un jeu de paramètres, ou plus globalement, selon les préceptes introduits dans la présente, la gestion centralisée d’un très grand nombre de configurations par l’opérateur de l’infrastructure du réseau de communication est rendue possible en implémentant des moyens de décision locaux et grâce à la conception modulaire des piles protocolaires : le comportement de chaque mécanisme peut être influencé en temps réel par des décisions locales, prises au niveau du compteur intelligent, comme cela est détaillé par la suite. En d’autres termes, une telle architecture permet d’effectuer des mises à jour ciblées et partielles des micrologiciels nécessitant une évolution ; Cette architecture évite alors les mises à jour de micrologiciels monolithiques volumineux, en favorisant des mises à jour légères de FCV ciblées constitutives de la pile protocolaire à faire évoluer. Les communications effectuées à l’occasion des mises à jour sont donc plus courtes (moins de blocs à transmettre et moins d’octets par bloc), ce qui minimise les échecs de communication, les retransmissions et donc la congestion du réseau sous-jacent. Ces mises à jour se font via le mécanisme de chargement/déchargement des FCV, grâce au module de gestion OMFCV (bloc d’orchestration et de management des FCV) interagissant avec le contrôleur CONT (qui initie le processus de mise à jour). De manière corollaire, ce mécanisme de chargement/déchargement des FCV peut également être utilisé pour doter uniquement certains nœuds du réseau avec des FCV spécifiques. Un exemple de découpage en FCV de la pile protocolaire intégrant les fonctionnalités spécifiées dans la norme ITU-T G.9903 (en particulier pour la technologie G3-Hybrid) est représenté en FIG. 2 . Plus particulièrement, la FIG. 2 illustre les couches protocolaires suivantes : la couche applicative APPLy, la couche transport TLy, la couche IP, les deux couches « data link layer » (IETF6LoPWAN et MAC) et la couche physique (PLC-Phy et Sun FSK). Dans cet exemple, les deux couches « data link layer » (couches de liaison de données) et la couche physique sont virtualisées en autant de FCV que nécessaire. La couche physique est virtualisée et comprend un premier ensemble de fonctions pour la gestion de la couche physique CPL (FCV PLC PHY LYR) et un deuxième ensemble de fonctions pour la gestion de la couche physique RF (FCV RF PHY LYR). La couche MAC est virtualisée et comprend un premier ensemble de fonctions MAC RF (FCV RF MAC LYR) et un deuxième ensemble de fonctions MAC CPL (FCV PLC MAC LYR). La couche LLC est virtualisée et comprend les fonctions nécessaires à la mise en œuvre de la couche 6LoWPAN dérivée des spécifications de l’IETF (FCV 6LowPAN) et de la couche d’abstraction faisant le lien entre 6LoWPAN et la couche MAC RF (FCV Abs LYR). Ainsi, chaque FCV dispose d’interfaces de type API pour interagir avec d’autres FCV ou avec l’environnement de virtualisation (EV), qui désigne l’environnement logiciel d’exécution de la pile protocolaire faisant le lien avec les ressources matérielles locales (capacités de calcul, mémoire, etc.). L’architecture logicielle et matérielle d’un dispositif électronique de mesure de consommation d’une ressource (IPMx) hébergeant une pile protocolaire G3-Hybrid découpée en FCV est représentée en FIG. 3 . Cette représentation de la FIG. 3 fait apparaitre un dispositif électronique de mesure de consommation d’une ressource (IPMx) comprenant des ressources matérielles, à savoir un processeur P, une mémoire RAM M et une mémoire Flash Fl, et un modem MIG G3-Hybrid et comprenant par exemple deux SOC (de l’anglais « System-on-(a-)Chip. ») : un SOC dédié aux communications CPL et un SOC dédié aux communications RF, chaque SOC comprenant un processeur de traitement de signal DSP, une mémoire flash Fl, une mémoire RAM M, un convertisseur analogique numérique ADC, un convertisseur numérique analogique DAC et pour chacun un front end analogique (An F.E). Il est également possible de ne disposer que d’un SOC unique (DSP/Flash/RAM/DAC/ADC) ainsi qu’un Front End Analogique RF et un Front End Analogique PLC, pour des soucis d’implémentation et/ou d’économie. Le micrologiciel du dispositif électronique de mesure de consommation d’une ressource (IPMx) embarque un environnement de virtualisation EV comprenant un système d’exploitation OS et une couche de virtualisation (VIRT LYR) prenant par exemple la forme d’une machine virtuelle. Cet environnement de virtualisation est chargé au démarrage du dispositif électronique de mesure de consommation d’une ressource (IPMx) et constitue le socle d’exécution des FCV. Le module de gestion OMFCV des fonctions virtualisées de communication FCV, met en œuvre les fonctions de gestion et d’orchestration des FCV. Ce composant a la charge de la conduite de l’exécution des différentes FCV en fonction de paramètres d’orchestration, notamment pour l’orchestration et l’ordonnancement des appels des différentes FCV dans l’objectif de répondre à une fonction globale de communication. Pour ce faire, le module de gestion OMFCV fait appel à des API qui permettent d’exécuter les différentes fonctions des FCV. Les API des FCV sont définies en fonction des besoins fonctionnels d’échange entre FCV et avec l’environnement de virtualisation. Les FCV sont quant à elle regroupées dans une ou plusieurs bibliothèques FCVLib, au sein desquelles elles sont stockées pour être appelées. On note qu’une même FCV peut être présente dans plusieurs versions différentes au sein de la bibliothèque FCV Lib et que le module de gestion OMFCV appelle et exécute les FCV en fonction des paramètres qu’il reçoit ou détermine. Ainsi, les différentes FCV de la pile protocolaire sont appelées, par le module de gestion OMFCV, lors des opérations de réception et de transmission des messages au niveau des différentes couches ISO/OSI de la pile protocolaire et selon les autres traitements nécessaires au bon fonctionnement du modem MIG. Un avantage de cette architecture réside dans sa modularité, et plus particulièrement dans la facilité avec laquelle il est possible de réaliser des mises à jour de FCV sans qu’il soit nécessaire de mettre à jour l’intégralité du micrologiciel du modem MIG. En effet, selon les fonctions protocolaires portées par les FCV et les implémentations cibles, les FCV peuvent être « chargées » ou « déchargées » de la bibliothèque FCVLib à disposition du module de gestion OMFCV selon les décisions d’un contrôleur CONT centralisé comme illustré en FIG. 4 (le contrôleur CONT décide de charger ou décharger des FCV spécifique dans les bibliothèques d'un, d'une partie ou de tous les IPMx du réseau) ou selon les décisions d’un module local à chaque IPMx du réseau (par exemple lorsque qu’un tel module local existe et est en mesure de prendre des décisions de ce type, comme cela est exposé par la suite). Dans l’exemple de la FIG. 4 , le contrôleur dispose d’une bibliothèque FCVLib dans laquelle toutes les FCV (exemple FCVx, FCVy) sont disponibles. En fonction de conditions qu’il rencontre, qu’il analyse ou qu’il détermine, le contrôleur CONT est en mesure de faire parvenir une ou plusieurs FCV, aux dispositifs électroniques de mesure de consommation de ressource (i0,… i12), par l’intermédiaire du réseau de communication (sur la FIG. 4 un réseau maillé est décrit). Le contrôleur CONT est en mesure de sélectionner par exemple une ou plusieurs FCV à transmettre à tout ou partie des dispositifs électroniques de mesure de consommation de ressource (i0,… i12). Chaque FCV peut être empaquetée dans un fichier dédié, par le contrôleur CONT avec des paramètres d’exécution. En fonction des réalisations, le fichier dédié peut également ne contenir que des paramètres d’exécution dédiés à une FCV. Sur l’exemple de la FIG. 4 , le routage de la FCV0 est effectué vers les dispositifs électroniques de mesure de consommation de ressource i5 et i2, par le réseau maillé. Ce contrôleur CONT peut être exécuté en edge computing en bordure du réseau (par exemple une passerelle, un routeur ou un concentrateur), soit hébergé dans le système d’information central en cloud computing. Par ailleurs, dans le cas où les contrôleurs CONT sont localisés en bordure de réseaux de communication distribués à l’échelle d’un territoire, des échanges inter-contrôleurs peuvent être effectués au sein d’une même infrastructure. Par exemple, la FCV correspondant au modulateur et démodulateur OFDM de la couche PHY CPL n’a pas vocation à être déchargée de l’environnement de virtualisation du modem MIG en fonctionnement nominal, cependant d’autres FCV peuvent, elles, être chargées sur des périodes finies et uniquement sur une sélection d’objets communicants, selon les fonctionnalités devant être supportées par ces objets ou à des fins d’optimisation de l’utilisation des ressources (CPU, RAM, batterie, etc.) disponibles dans chaque objet. Cela peut être le cas d’une FCV couvrant la connectivité radio avec des objets communicants sur batterie, au sein d’un réseau local de l’habitation du consommateur. Selon l’invention, en plus d’une identité « fonctionnelle », l’architecture du modem MIG objet de la divulgation peut comprendre des fonctions complémentaires qui ne sont pas implémentables avec l’architecture actuelle de tels dispositifs. Par exemple, des API additionnelles sont définies sur les FCV pour permettre aux FCV de peupler une base de données locale avec des données dont la nature est propre à chaque FCV. Ces données sont par exemple les suivantes : niveau de bruit mesuré sur le réseau électrique (CPL) ou "dans l'air" (radio) ; atténuation entre les nœuds ; évolution des routes construites à travers le réseau maillé ; atténuation mesurée vers les nœuds voisins (accessible "en un saut") ; détection d'une signature d'un bruit électromagnétique sur le réseau (e.g. un niveau de tension dans une bande de fréquence déterminée). Les jeux de données stockés dans la base de données locale, propre au modem MIG peuvent alors faire l’objet de traitement simples ou plus avancés dans le cadre d’un processus exécuté parallèlement à la pile protocolaire, par exemple par une ou plusieurs FCV dédiée(s) et non affectée(s) à la pile protocolaire ou encore un ou plusieurs processus dédié(s) distinct(s), en utilisant des ressources matérielles dédiées ou non (comme un processeur d’apprentissage automatique). Les traitements de type « avancés » peuvent par exemple utiliser des techniques d’intelligence artificielle telles que (mais non limitées à) l’apprentissage supervisé, l’apprentissage non supervisé ou encore l’apprentissage par renforcement. Ces traitements peuvent par exemple être des traitements d’identification et de localisation d'une source de bruit responsable d'interférences électromagnétiques ; d’identification ou de calcul (local) d'un jeu de paramètres optimal pour une ou plusieurs FCV ; de calcul du niveau d'occupation/de congestion local (au niveau de cet IMPx) du réseau ; de prédiction de la congestion sur la base d'un historique de données afin de mieux planifier les communications qui peuvent l'être. De tels traitements permettent par exemple d’obtenir des indicateurs pour ajuster le comportement des FCV de la pile protocolaire, soit en temps réel et localement (edge computing dans le dispositif électronique de mesure de consommation d’une ressource IPMx), soit de manière centralisée au niveau d’un dispositif électronique proche (par exemple une passerelle, un routeur ou un concentrateur : « edge computing » en bordure de réseau) ou au niveau du système central (« cloud computing »). Dans une réalisation de l’invention, les données sont collectées au niveau du modem MIG, dans une base de données locale. Le module de gestion OMFCV, par l’intermédiaire d’une fonction virtualisée particulière, effectue une analyse de ces données, par exemple pour calculer des métriques qui se basent sur les données de diagnostic ou de mesures collectées par l’intermédiaire des API des FCV de la pile protocolaire. Selon une première possibilité de traitement, ces métriques sont fournies à un réseau de neurones, (par exemple exécuté au sein d’une FCV de prise de décision ou bien sur un processeur dédié (non représenté) du dispositif électronique de mesure de consommation de ressource IPMx, à l’aide d’un logiciel dédié), pour fournir aux FCV de gestion de la pile protocolaire, par l’intermédiaire du module de gestion OMFCV, des paramètres d’adaptation de leurs fonctionnements. Le terme « réseau de neurones » désigne tout réseau favorisant l'intelligence artificielle, en particulier pour l’apprentissage automatique, et peut se référer à d’autres types de réseaux tels que les réseaux Bayésiens, SVM ,… choisi selon le besoin. Selon une deuxième possibilité de traitement, ces métriques sont fournies à un système centralisé de prise de décision (par exemple via le contrôleur CONT), lequel utilise les métriques qu’il reçoit de la part des modems hybrides MIG pour déterminer des paramètres de fonctionnement adapté à une grappe de modems hybride MIG. La transmission de ces paramètres de fonctionnement aux modems hybrides MIG, via le réseau de communication, permet d’adapter par exemple le fonctionnement de ces modems hybrides MIG lorsqu’ils font face à des conditions de réception/transmission de données défavorables, du fait de perturbations sur le réseau de communication qu’ils utilisent. La transmission de ces paramètres, s’ils font suite à des perturbations rencontrées sur le seul medium CPL, peut alors astucieusement être effectuée sur le réseau maillé par l’intermédiaire du deuxième medium RF. Le processeur du réseau de neurones peut également être mis en œuvre pour d’autres applications que l’ajustement de paramètres. Ainsi, l’ajustement des comportements des FCV de la pile protocolaire se fait sur la base d’une décision qui peut être prise à plusieurs niveau de l’infrastructure du réseau de communication : Au niveau du contrôleur CONT, qu’il soit hébergé au niveau du système central ou dans un équipement en bordure du réseau de communication (par exemple une passerelle, un routeur ou un concentrateur). Celui-ci peut alors décider de reparamétrer certaines FCV avec des jeux de paramètres spécifiques voire de mettre à jour ces FCV en ajoutant/retirant des mécanismes protocolaires (on parle alors de la mise à jour d’une partie seulement du micrologiciel de la pile protocolaire d’accès au réseau de communication). Au niveau du dispositif électronique de mesure de consommation d’une ressource IPMx lui-même : le contrôleur CONT délègue la responsabilité de prise de décision au dispositif électronique de mesure de consommation d’une ressource IPMx. Dans ce cas des précautions particulières devront être prises pour s’assurer que le comportement des FCV impactées par la décision évolue entre des bornes prédéfinies pour éviter des dysfonctionnements majeurs et pour permettre aux opérateurs du réseau de communication de garder le contrôle de l’infrastructure : la continuité de la connectivité et la disponibilité du modem MIG embarqué doivent être assurées. Ainsi, ce mécanisme contribue à résoudre la deuxième problématique rencontrée par les réseaux maillés de dispositifs électroniques de mesure de consommation de ressource, à savoir la rigidité des piles protocolaires qui sont conçues à l’échelle d’un système et sont peu capables de s’adapter à un environnement de communication local spécifique ou à des besoins fonctionnels évolutifs. L’architecture modulaire des piles protocolaires décrite dans la présente, associée à des moyens de calcul locaux (dans le modem) ou en bordure de réseau contribue à la plasticité des piles protocolaires. Ces dernières sont capables, grâce à l’architecture de la divulgation, de s’adapter localement aux contraintes rencontrées et assurer un fonctionnement optimisé de l’infrastructure réseau (par une meilleure adéquation de la FCV sélectionnée dans la pile protocolaire aux besoins et contraintes subies par les objets communicants). Des prises de décisions au niveau du système central peuvent également être mises en œuvre pour garantir la pilotabilité de l’infrastructure réseau. D’une manière générale, le procédé mis en œuvre entre le contrôleur CONT et les dispositifs électroniques de mesure de consommation de ressource IPMx qui sont connectés à ce contrôleur sont les suivants : le contrôleur transmet, sur le réseau maillé, à destination d’un ou de plusieurs dispositifs électroniques IPMx, un fichier dédié FFCV comprenant une ou plusieurs FCV ; du fait de la nature des FCV, ces fichiers dédiés sont de tailles réduites et donc le fichier dédié est de taille très inférieure à celle d’un micrologiciel complet ; cette transmission est effectuée selon le standard initialement sélectionné par le gestionnaire du réseau (par exemple PRIME, G3-PLC, G3-Hybrid, WiSUN) ; à réception du fichier dédié FFCV, le dispositif électronique IPMx met en œuvre les processus standards de la norme en question (par exemple PRIME, G3-PLC, G3-Hybrid, WiSUN) pour valider ce fichier dédié (i.e. vérifier que l’ensemble des trames est reçu et optionnellement que le CRC est correct par exemple) et pour en extraire le contenu ; à la différence des processus standards, cependant, le dispositif électronique IPMx ne met pas en œuvre un processus de mise à jour du micrologiciel : il procède à un enregistrement, au sein d’une bibliothèque de fonctions virtualisées, de la FCV (ou des FCV) qui sont extraits du fichier dédié ; cette FCV est enregistrée avec son numéro de version ; le fichier dédié peut également comprendre un ensemble de paramètres, qui sont spécifiques à la FCV transmise (il peut s’agit par exemple de paramètre d’appel de cette FCV destiné au module de gestion OMFCV) et/ou de paramètres généraux dont l’objet est par exemple d’adapter le comportement du dispositif électronique IPMx dans certaines situations ; ces paramètres sont enregistrés, également dans une bibliothèque de paramètres à disposition du module de gestion OMFCV ; dans certaines situations, par ailleurs, et conformément aux processus standards de la norme en question (par exemple PRIME, G3-PLC, G3-Hybrid, WiSUN), le fichier dédié peut être retransmis à d’autres dispositifs électroniques IPMx dans le réseau maillé ; dans d’autres situations, le fichier dédié peut être uniquement destiné à être pris en compte par certains dispositifs électroniques IPMx pour la mise en œuvre de fonctions particulières, auquel cas il ne fait pas nécessairement l’objet de retransmission. Comme indiqué précédemment, le dispositif électronique IPMx, pour sa part, à l’aide du module de gestion OMFCV, dispose d’une fonction d’orchestration et d’ordonnancement de l’exécution des FCV. Il pilote notamment les exécutions des différentes FCV pour fournir des fonctionnalités de réception et de transmission de messages sur le ou les réseaux de communication, en fonction de paramètres qui sont transmis par le contrôleur CONT et/ou en fonction de paramètres qu’il détermine sur la base des données récoltées (à l’aide des API des FCV). Selon l’invention, le module de gestion OMFCV met également en œuvre des FCV d’analyse de ces données, par exemple par l’intermédiaire de réseaux de neurones, qui sont en charge de déterminer, en fonction des données qui sont insérées dans la base de données à partir des API des FCV, des paramètres adaptatifs de comportement, qui peuvent consister par exemple à modifier la taille des paquets de données transmis, à privilégier le medium RF ou au contraire à privilégier le medium CPL dans le cas d’une technologie hybride. L’invention a été typiquement décrite dans le cadre d’un réseau de distribution de ressources (gaz, électricité) ou elle permet de répondre à des problématiques de congestion du ou des réseaux de communications, par exemple des réseaux CPL, comme exposé préalablement. L’invention peut également être mise en œuvre dans d’autres configurations, telle que des configurations et des réseaux de type IoT. Une infrastructure de réseau IoT (« Internet of Things ») est un système qui permet de connecter des objets physiques, de collecter des données en temps réel et de communiquer avec eux à distance. Une infrastructure de réseau IoT se compose de plusieurs éléments. Les capteurs et/ou Les actionneurs sont des dispositifs qui mesurent des paramètres physiques et agissent sur l'environnement physique en réponse à des commandes électroniques. Les passerelles sont des dispositifs qui connectent les capteurs et les actionneurs au réseau IoT en utilisant différents protocoles de communication. Les plateformes de gestion de données sont des logiciels qui permettent de collecter, de stocker, de traiter et d'analyser les données générées par les capteurs et les actionneurs. Les réseaux de communication sont des infrastructures qui permettent aux capteurs, aux actionneurs et aux passerelles de communiquer entre eux et avec les plateformes de gestion de données. Enfin, les applications sont des logiciels qui permettent aux utilisateurs d'interagir avec les objets connectés et de visualiser les données collectées. Les capteurs et les actionneurs sont les éléments clés d'une infrastructure de réseau IoT. Ils permettent de mesurer des paramètres physiques tels que la température, l'humidité, la pression, etc., et d'agir sur l'environnement physique en réponse à des commandes électroniques. Les capteurs peuvent être installés dans des environnements variés, tels que des bâtiments, des véhicules, des équipements industriels, etc. Les actionneurs peuvent être utilisés pour contrôler des moteurs, des vannes, des interrupteurs, etc. Les capteurs et les actionneurs peuvent communiquer avec les passerelles en utilisant différents protocoles de communication, tels que Zigbee, Bluetooth, Wi-Fi, LoRaWAN, etc. En fonction des situations, la fonction de capteur et d’actionneur est regroupée au sein d’un même dispositif. Les passerelles sont des dispositifs qui connectent les capteurs et les actionneurs du réseau IoT. Elles peuvent être filaires ou sans fil et peuvent utiliser différents protocoles de communication. Les passerelles peuvent être installées dans des environnements variés, tels que des bâtiments, des véhicules, des équipements industriels, etc. Les passerelles peuvent également effectuer des traitements de données locaux, tels que la compression de données, le filtrage de données, etc., avant de transmettre les données aux plateformes de gestion de données. Les plateformes de gestion de données sont des logiciels qui permettent de collecter, de stocker, de traiter et d'analyser les données générées par les capteurs et les actionneurs. Elles peuvent être hébergées sur des serveurs locaux ou dans le cloud. Les plateformes de gestion de données peuvent offrir des fonctionnalités de visualisation de données en temps réel, d'analyse de données, d'alerte en cas de dépassement de seuils, etc. Les réseaux de communication sont des infrastructures qui permettent aux capteurs, aux actionneurs et aux passerelles de communiquer entre eux et avec les plateformes de gestion de données. Ils peuvent utiliser différentes technologies de communication, telles que les réseaux cellulaires, les réseaux sans fil, les réseaux filaires, etc. Enfin, les applications sont des logiciels qui permettent aux utilisateurs d'interagir avec les objets connectés et de visualiser les données collectées. Elles peuvent être installées sur des ordinateurs, des smartphones, des tablettes ou d'autres appareils électroniques. Les applications peuvent offrir des fonctionnalités avancées, telles que la visualisation de données en temps réel, l'analyse de données, l'alerte en cas de dépassement de seuils, etc. Les applications peuvent également offrir des interfaces conviviales pour permettre aux utilisateurs de contrôler les objets connectés à distance. Dans le cadre de l’invention, des dispositifs IoT de l’architecture qui vient d’être décrite peuvent être configurés en utilisant les modules précédemment décrits, par exemple pour assurer une transmission efficace des données au sein du ou des réseaux de communication. Notamment, ces dispositifs IoT peuvent être les capteurs, actionneurs et/ou passerelles décrites précédemment et peuvent embarquer un environnement de virtualisation permettant la mise en œuvre de fonctions de communications virtualisées, associées au non à un modem de type modem CPL, radio ou hybride. Dispositif électronique de mesure de consommation d’une ressource (IPMx) comprenant : un processeur (P) et une mémoire (M) ; un modem (MIG), pour transmettre et recevoir des données par l’intermédiaire d’au moins un medium de communication (CPL, RF) à l’aide d’un standard de communication, utilisé par un réseau de communication d’un fournisseur de la ressource auquel le dispositif électronique de mesure de consommation de la ressource (IPMx) est connecté ; un module de gestion (OMFCV) de fonctions virtualisées de communication (FCV), ledit module de gestion (OMFCV) étant configuré pour charger, à partir de la mémoire (M), au moins une fonction virtualisée de communication (FCV) à exécuter par le modem (MIG), ladite au moins une fonction virtualisée de communication (FCV) ayant été préalablement transmise et/ou paramétrée, à l’aide d’un fichier dédié (FFCV), provenant d’un contrôleur (CONT) connecté au dispositif électronique de mesure de consommation de la ressource (IPMx) par l’intermédiaire du réseau de communication. Dispositif électronique de mesure de consommation de ressource (IPMx) selon la revendication 1, caractérisé en ce que le fichier dédié (FFCV) est reçu en lieu et place d’un fichier de mise à jour du micrologiciel du dispositif électronique de mesure de consommation de ressource (IPMx). Dispositif électronique de mesure de consommation de ressource (IPMx) selon la revendication 1, caractérisé en ce qu'il comprend au moins une base de données embarquée pour l’enregistrement, en provenance d’au moins une des fonctions virtualisées de communication (FCV), de données de suivi d’exécution. Dispositif électronique de mesure de consommation de ressource (IPMx) selon la revendication 3, caractérisé en ce qu’il comprend des moyens d’adaptation du fonctionnement d’au moins une des fonctions virtualisées de communication (FCV) en fonction des données de suivi d’exécution de ladite au moins une base de données embarquée. Dispositif électronique de mesure de consommation de ressource (IPMx) selon la revendication 3, caractérisé en ce qu'il comprend au moins un réseau de neurones configuré pour fournir des paramètres d’adaptation d’au moins une des fonctions virtualisées de communication (FCV) en fonction des données de suivi d’exécution de ladite au moins une base de données embarquée. Dispositif électronique de mesure de consommation de ressource (IPMx) selon la revendication 1, caractérisé en ce que le fichier dédié (FFCV) comprend au moins un paramètre d’adaptation de fonctionnement d’au moins une des fonctions virtualisées de communication (FCV) installée au sein du dispositif électronique de mesure de consommation de ressource (IPMx). Dispositif électronique de mesure de consommation de ressource (IPMx) selon la revendication 1, caractérisé en ce qu’un premier medium de communication est de type courant porteur en ligne (CPL) et en ce que qu’un deuxième medium de communication est de type radiofréquence (RF) et en ce que le modem (MIG) est un modem hybride. Dispositif électronique de mesure de consommation de ressource (IPMx) selon la revendication 1, caractérisé en ce que le dispositif électronique de mesure de consommation de la ressource (IPMx) est un compteur électrique intelligent. Système (Syst) de contrôle d’une pluralité de dispositifs de mesure de consommation d’une ressource (IPMx), le système comprenant : un réseau de communication ; la pluralité de dispositifs de mesure de consommation de la ressource (IPMx), chaque dispositif de mesure de consommation de la ressource comprenant : un processeur et une mémoire ; un modem, pour transmettre et recevoir des données par l’intermédiaire d’au moins un medium de communication à l’aide d’un standard de communication, utilisé par un réseau de communication d’un fournisseur de la ressource auquel le dispositif électronique de mesure de consommation de la ressource est connecté ; un module de gestion d’au moins une fonction virtualisée de communication, le module de gestion étant apte à charger, à partir de la mémoire, au moins une fonction de communication à exécuter par le modem ; un contrôleur (CONT), connecté à la pluralité des dispositifs de mesure de consommation de la ressource (IPMx) par l’intermédiaire du réseau de communication, le contrôleur étant apte à transmettre, à toute ou partie de la pluralité de dispositifs de mesure de consommation de la ressource (IPMx), une pluralité de fichiers de mise à jour de fonction de communication, la taille des fichiers de mise à jour de fonction étant réduite par rapport à la taille du micrologiciel du modem. Dispositif électronique de type capteur et/ou actionneur appartenant à une infrastructure de communication de type internet des objets, comprenant : un processeur (P) et une mémoire (M) ; un modem (MIG), pour transmettre et recevoir des données par l’intermédiaire d’au moins un media de communication (CPL, RF) à l’aide d’un standard de communication utilisé par un réseau de communication de l’infrastructure de communication de type internet des objets auquel le dispositif électronique est connecté ; un module de gestion (OMFCV) de fonctions virtualisées de communication (FCV), ledit module de gestion (OMFCV) étant configuré pour charger, à partir de la mémoire (M), au moins une fonction virtualisée de communication (FCV) à exécuter par le modem (MIG), ladite au moins une fonction virtualisée de communication (FCV) ayant été préalablement transmise et/ou paramétrée, à l’aide d’un fichier dédié (FFCV), provenant d’un contrôleur (CONT) connecté au dispositif électronique par l’intermédiaire du réseau de communication.