FR 3081271 A1 20191122 FR 1854114 A 20180517 La présente invention concerne un équipement adapté pour être connecté à un système de gestion automatique de relevés de compteurs électriques, un système de communication comprenant ledit équipement et des procédés exécutés au moins en partie par ledit équipement. Les réseaux de transport d'électricité, tels que le réseau public de transport 10 d'électricité français, ont vocation à acheminer des quantités importantes d'électricité sur de grandes distances. Ces réseaux sont généralement appelés réseaux hautes tensions (réseaux HT) puisqu'ils transportent des courants ayant une tension supérieure à « 50» kV. Ces réseaux HT sont équipés de capteurs et d'actionneurs permettant de gérer ces réseaux. Les capteurs sont par exemple des capteurs de 15 température, de pression ou de mouvement, et les actionneurs par exemple des commutateurs (« switches » en terminologie anglo-saxonne). Une telle gestion, dite intelligente, permet notamment d'adapter à tout moment une production et une consommation d'électricité sur les réseaux HT, ce qui permet notamment de réaliser des économies d'énergie et de contourner des défaillances du réseau. 20 Les réseaux de distribution d'électricité quant à eux sont destinés à acheminer l'électricité sur de plus courtes distances pour une alimentation de la consommation locale, mais aussi pour un raccordement de nombreux producteurs d'électricité de petite et moyenne puissance. Ces réseaux sont généralement appelés réseaux moyennes ou basses tensions (réseaux MT ou BT) puisqu'ils transportent des courants 25 ayant respectivement une tension comprise entre « 1» kV et « 50» kV et inférieure à « 1» kV. Un besoin de gestion intelligente de ce type de réseaux se fait aussi ressentir d'une part pour mieux gérer les défaillances des réseaux MT et BT et réaliser des économies d'énergie, mais aussi d'autre part pour mieux intégrer la production d'électricité par énergie renouvelable. Actuellement aucune solution n'existe pour 30 permettre une gestion intelligente des réseaux MT et BT à l'image de ce qui se fait dans les réseaux HT. Il existe pourtant des moyens de communication, notamment dans les réseaux BT, permettant de remonter vers une unité centralisée des informations émanant de terminaux du réseau BT. Les réseaux de communication par courants porteurs en ligne (« PowerLine Communications » en terminologie anglo-saxonne) pour des systèmes de type AMM (gestion automatique de relevés de compteurs, « Automated Meter Management » en terminologie anglo-saxonne) utilisent ainsi des infrastructures de réseaux BT (réseau physique) pour créer un réseau, dit réseau logique. Parmi ces réseaux logiques, dits réseaux CPL (Courants Porteurs en Ligne), on peut citer les réseaux conformes aux spécifications PRIME (« PoweRline Intelligent Metering Evolution » en terminologie anglo-saxonne) ou les réseaux conformes au standard G3- PLC spécifié dans la recommandation ITU-T G.9903. Dans les réseaux CPL, des communications sont établies entre des compteurs électriques, dits intelligents (« smart electrical meters » en terminologie anglo-saxonne), et un dispositif appelé concentrateur de données (« data concentrator » en terminologie anglo-saxonne) pour permettre notamment une relève automatisée à distance de mesures de consommation électrique effectuées par lesdits compteurs électriques intelligents. Par la suite nous appelons simplement compteur chaque compteur électrique intelligent. Une pluralité de concentrateurs de données est typiquement géographiquement déployée dans un réseau CPL de manière à répartir la charge de gestion à distance d'une multitude de compteurs. Chaque concentrateur de données est lui-même connecté à une même unité centralisée permettant la gestion du système de type AMM qui est gérée par un opérateur du réseau d'alimentation électrique auquel lesdits compteurs sont connectés. Comme l'indique l'acronyme AMM, les réseaux CPL pour les systèmes de type AMM sont destinés à gérer des données de métrologie émanant de compteurs. Les réseaux CPL ne permettent donc pas de remonter des informations provenant de capteurs, ni de contrôler des actionneurs. Avec l'apparition récente de l'internet des objets (« Internet of Things (IoT) » en terminologie anglo-saxonne) est apparu un nouveau type de réseaux : les réseaux sans fils à grande portée et à faible consommation d'énergie (« Low Power Wide Area Network (LPWAN) », en terminologie anglo-saxonne). Parmi ces réseaux LPWAN, on peut citer des réseaux basés sur la technologie LoRa (marque déposée) (« Long Range» en terminologie anglo-saxonne). Un réseau basé sur la technologie LoRa (appelé « réseau LoRa » par la suite) utilise un protocole appelé LoRaWAN. Un réseau LoRa est composé de stations de base ou passerelles (« gateways » en terminologie anglo-saxonne) généralement placées sur des points hauts afin de couvrir une grande zone géographique. Les passerelles sont aptes à détecter des messages émis dans leur zone par des 3 équipements ou terminaux (« endpoints » en terminologie anglo-saxonne) et à les remonter vers au moins un serveur (« LoRa Network Server (LNS) » en terminologie anglo-saxonne) qui les traitera. Dans un fonctionnement classique d'un réseau LoRa, un terminal désirant 5 transmettre un message (i.e. des données) au serveur, transmet ce message dans une trame, dite trame montante, conforme au protocole LoRaWAN. La trame montante est transmise en mode multidiffusion (« broadcast » en terminologie anglo-saxonne). Cette trame montante est reçue par au moins une passerelle. Chaque passerelle ayant reçu la trame la décode et retransmet le message au serveur dans une requête HTTP 10 (protocole de transfert hypertext, « HyperText Transfer Protocol » en terminologie anglo-saxonne). Si plusieurs passerelles ont reçu la trame, le serveur reçoit plusieurs requêtes HTTP contenant le message. Le serveur doit alors désigner parmi les passerelles ayant reçu la trame montante, la passerelle à utiliser pour relayer une réponse au message contenu dans la trame montante. La réponse est transmise du 15 serveur à la passerelle désignée dans une requête HTTP, puis en point à point, de la passerelle désignée au terminal dans une trame descendante conforme au protocole LoRaWAN. Il semble donc que les réseaux LoRa seraient une solution intéressante pour permettre à des capteurs ou des actionneurs utilisés pour gérer un réseau BT de 20 communiquer avec une unité centralisée. Toutefois, il est connu que les réseaux BT couvrent très finement des territoires, ce qui n'est pas le cas des réseaux LPWAN tels que les réseaux LoRa. Certaines zones couvertes par les réseaux BT ne sont pas couvertes par un réseau LPWAN. Or, la remontée d'informations de capteurs et le contrôle d'actionneurs doivent aussi être possibles dans ces zones non couvertes. Par 25 ailleurs, les réseaux LoRa sont des réseaux publics, partagés par beaucoup d'utilisateurs. Transmettre des données sensibles telles que des données permettant une gestion d'un réseau BT sur un réseau LoRa peut paraître risqué. Il est souhaitable de pallier ces inconvénients de l'état de la technique. Il est notamment souhaitable de proposer une solution qui permette à une unité centralisée 30 de recevoir des informations de capteurs et/ou de contrôler des actionneurs situés dans n'importe quelles zones d'un réseau BT. Il est de plus souhaitable de fournir une solution qui soit simple à mettre en oeuvre et à faible coût. Selon un premier aspect de la présente invention, la présente invention concerne un équipement adapté pour être connecté à un système de gestion automatique de relevés de compteurs électriques, dit système AMM, le système AMM comprenant au moins un concentrateur de données auquel sont rattachés des compteurs électriques 5 intelligents, dit compteurs, via un premier réseau par courants porteurs en ligne, chaque concentrateur de données étant connecté à un système de gestion comprenant une entité de gestion via un deuxième réseau et servant de relais entre lesdits compteurs et le système de gestion. L'équipement est connecté à un concentrateur de données, dit concentrateur relai via un troisième réseau, ledit équipement comprend au 10 moins une interface de communication avec un quatrième réseau, ledit quatrième réseau permettant à au moins un dispositif connecté audit quatrième réseau de communiquer avec l'équipement. Ledit équipement étant apte à recevoir des données d'un ou plusieurs dispositifs connectés au quatrième réseau, à vérifier que les données reçues sont conformes à un critère prédéterminé dépendant d'un type des données 15 transmises et à transmettre une alarme à un serveur d'administration compris dans le système de gestion en cas de non-conformité desdites données ; et, apte à relayer une commande émise par le serveur d'administration et destinée à un dispositif connecté au quatrième réseau. De cette manière, l'équipement permet de bénéficier du système de type AMM 20 pour remonter des données au serveur d'administration. Selon un mode de réalisation, l'équipement comprend une première interface de communication avec un premier quatrième réseau de type à grande portée et à faible consommation d'énergie, dit réseau de type LPWAN, et/ou une seconde interface de communication avec un deuxième quatrième réseau de type filaire. 25 Selon un deuxième aspect de l'invention, l'invention concerne un système de communication basé sur un système de gestion automatique de relevés de compteurs électriques, dit système AMM, comprenant au moins un équipement selon le premier aspect. Selon un mode de réalisation, chaque dispositif connecté au premier ou au 30 deuxième quatrième réseau est un capteur ou un actionneur. Selon un mode de réalisation, le deuxième quatrième réseau est un réseau de type R5485 et chaque donnée ou commande transmise sur le deuxième quatrième réseau est transmise dans une trame conforme au protocole Modbus. 5 Selon un mode de réalisation, chaque donnée ou commande transmise sur le réseau de type LPWAN est transmise dans une trame conforme à un protocole propriétaire utilisant une couche physique identique à une couche physique utilisée par le protocole LoRaWAN et un format de charges utiles de niveau applicatif 5 propriétaire. En utilisant un protocole propriétaire, on évite des problèmes de sécurité inhérents à des réseaux partagés tels que les réseaux LoRa. Selon un mode de réalisation, le format de charge utile propriétaire comprend un premier champ permettant de définir un type de dispositif impliqué soit en tant que 10 destinataire soit en tant qu'émetteur de la trame, un deuxième champ permettant de transporter une valeur représentative d'une commande lorsque la trame est destinée à un dispositif de type actionneur, une valeur représentative d'un type de données lorsque la trame est échangée avec un dispositif de type capteur ou une valeur représentative d'un accusé de réception, un troisième champ indiquant combien 15 d'octets de données sont présents dans la charge utile de la trame et optionnellement, en fonction d'une valeur du troisième champ, un ou plusieurs quatrièmes champs de données. Selon un mode de réalisation, le système est adapté pour exécuter une procédure de connexion lorsqu'un dispositif doit être connecté audit réseau de type LPWAN. La 20 procédure de connexion comprend : émettre, par ledit dispositif, une requête de connexion conforme au protocole propriétaire en mode multidiffusion ; relayer, par chaque équipement dudit système ayant reçu ladite requête, ladite requête vers le concentrateur relai auquel est rattaché l'équipement ; relayer, par chaque concentrateur relai auquel est rattaché un équipement ayant relayé la requête, ladite 25 requête vers l'entité de gestion ; choisir, par l'entité de gestion, parmi les équipements ayant relayé ladite requête, un équipement à associer avec ledit dispositif ; transmettre audit dispositif, par l'entité de gestion, via le concentrateur relai auquel est rattaché l'équipement choisi et l'équipement choisi, une requête d'autorisation de connexion. Selon un mode de réalisation, le système est adapté pour exécuter une procédure 30 de connexion lorsqu'un dispositif doit être connecté à un équipement par ledit deuxième quatrième réseau, la procédure de connexion comprenant : créer par ledit équipement, un dispositif virtuel représentant le dispositif devant être connecté au deuxième quatrième réseau ; créer, par ledit dispositif virtuel, une requête de connexion conforme au protocole propriétaire; transmettre, par l'équipement, à l'entité de gestion, via le concentrateur relai rattaché à l'équipement, la requête de connexion ; transmettre audit dispositif virtuel, par l'entité de gestion, via le concentrateur relai auquel est rattachée l'équipement et l'équipement, une requête d'autorisation de connexion. 5 Selon un mode de réalisation, le système est adapté pour exécuter une procédure de transmission d'une commande à un dispositif de type actionneur, la procédure de transmission d'une commande comprenant transmettre une commande audit dispositif, par le serveur d'administration, via l'entité de gestion, le concentrateur relai auquel est rattaché l'équipement associé audit dispositif de type actionneur et 10 l'équipement associé audit dispositif de type actionneur. Selon un mode de réalisation, la procédure de transmission d'une commande comprend en outre, transmettre, par ledit dispositif de type actionneur un accusé de réception pour la commande au serveur d'administration, via l'équipement associé audit dispositif de type actionneur, le concentrateur relai auquel est rattaché 15 l'équipement associé audit dispositif de type actionneur et l'entité de gestion. Selon un mode de réalisation, le système est adapté pour exécuter une procédure de transmission de données, la procédure de transmission de données comprenant pour chaque dispositif de type capteur transmettant des données, transmettre, par ledit dispositif de type capteur des données dans une trame conforme au protocole 20 propriétaire à l'équipement associé audit capteur, la transmission de l'alarme au serveur d'administration en cas de non-conformité de données reçues par un équipement se faisant via le concentrateur relai auquel est rattaché l'équipement ayant constaté ladite non-conformité. Selon un mode de réalisation, la transmission par ledit dispositif de type capteur 25 des données dans une trame conforme au protocole propriétaire à l'équipement associé audit dispositif de type capteur fait suite à une réception par ledit dispositif de type capteur d'une requête conforme au protocole propriétaire émise par ledit équipement demandant une transmission desdites données. Selon un troisième aspect de l'invention, l'invention concerne un procédé de 30 remontée d'alarme exécuté par un équipement connecté à un système de communication basé sur un système de gestion automatique de relevés de compteurs électriques, dit système AMM, le système AMM comprenant au moins un concentrateur de données auquel sont rattachés des compteurs électriques intelligents, dit compteurs, via un premier réseau par courants porteurs en ligne, chaque concentrateur de données étant connecté à un système de gestion comprenant une entité de gestion via un deuxième réseau et servant de relais entre lesdits compteurs et le système de gestion. L'équipement est connecté à un concentrateur de données, dit concentrateur relai via un troisième réseau et comprend au moins une première 5 interface de communication avec un premier quatrième réseau de type à grande portée et à faible consommation d'énergie, dit réseau de type LPWAN, ledit réseau de type LPWAN permettant à au moins un dispositif connecté audit réseau de type LPWAN de communiquer avec l'équipement en utilisant un protocole propriétaire utilisant une couche physique identique à une couche physique utilisée par le protocole LoRaWAN 10 et des trames comprenant une charge utile de niveau applicatif ayant un format propriétaire, et/ou au moins une deuxième interface de communication avec un deuxième quatrième réseau de type filaire dans lequel chaque données ou commande transmise est transmise dans une trame conforme au protocole Modbus. Le procédé comprend 15 recevoir d'un ou plusieurs dispositifs de type capteur des données dans une trame conforme au protocole propriétaire ; vérifier que les données reçues sont conformes à un critère prédéterminé dépendant d'un type des données transmises ; et, transmettre une alarme à un serveur d'administration compris dans le système de gestion en cas de non-conformité desdites données, la transmission se faisant via le concentrateur relai 20 et l'entité de gestion. Selon un quatrième aspect de l'invention, l'invention concerne un procédé de communication entre un dispositif et un serveur d'administration compris dans un système de communication basé sur un système de gestion automatique de relevés de compteurs électriques, dit système AMM, le système AMM comprenant au moins un 25 concentrateur de données auquel sont rattachés des compteurs électriques intelligents, dits compteurs, via un premier réseau par courants porteurs en ligne, chaque concentrateur de données étant connecté à un système de gestion comprenant le serveur d'administration et une entité de gestion via un deuxième réseau et servant de relais entre lesdits compteurs et le système de gestion. Le système de communication 30 comprend au moins un équipement connecté à un concentrateur de données, dit concentrateur relai via un troisième réseau, l'équipement comprenant au moins une interface de communication avec un quatrième réseau de type à grande portée et à faible consommation d'énergie, dit réseau de type LPWAN, ledit réseau de type LPWAN permettant à au moins un dispositif connecté audit réseau de type LPWAN 8 de communiquer avec l'équipement en utilisant un protocole propriétaire utilisant une couche physique identique à une couche physique utilisée par le protocole LoRaWAN et des trames comprenant une charge utile de niveau applicatif ayant un format propriétaire. Le procédé comprend une procédure de connexion dudit dispositif audit 5 quatrième réseau comprenant: émettre, par ledit dispositif, une requête de connexion conforme au protocole propriétaire en mode multidiffusion ; relayer, par chaque équipement dudit système ayant reçu la requête, ladite requête vers le concentrateur relai auquel est rattaché l'équipement ; relayer, par chaque concentrateur relai auquel est rattaché un équipement ayant relayé la requête, ladite requête vers l'entité de 10 gestion ; choisir, par l'entité de gestion, parmi les équipements ayant relayé ladite requête, un équipement à associer avec ledit dispositif ; transmettre audit dispositif, par l'entité de gestion, via le concentrateur relai auquel est rattaché l'équipement choisi et l'équipement choisi, une requête d'autorisation de connexion. Selon un cinquième aspect de l'invention, l'invention concerne un procédé de 15 communication entre un dispositif et un serveur d'administration compris dans un système de communication basé sur un système de gestion automatique de relevés de compteurs électriques, dit système AMM, le système AMM comprenant au moins un concentrateur de données auquel sont rattachés des compteurs électriques intelligents, dit compteurs, via un premier réseau par courants porteurs en ligne, chaque 20 concentrateur de données étant connecté à un système de gestion comprenant le serveur d'administration et une entité de gestion via un deuxième réseau et servant de relais entre lesdits compteurs et le système de gestion. Le système de communication comprend au moins un équipement connecté à un concentrateur de données, dit concentrateur relai via un troisième réseau, l'équipement comprenant au moins une 25 interface de communication avec un quatrième réseau de type filaire dans lequel chaque données ou commande transmise est transmise dans une trame conforme au protocole Modbus, et ce que le procédé comprend une procédure de connexion dudit dispositif audit quatrième réseau comprenant : créer par ledit équipement, un dispositif virtuel représentant le dispositif devant être connecté au quatrième réseau ; créer, par 30 ledit dispositif virtuel, une requête de connexion conforme au protocole propriétaire; transmettre, par l'équipement, à l'entité de gestion, via le concentrateur relai rattaché à l'équipement, la requête de connexion ; transmettre audit dispositif virtuel, par l'entité de gestion, via le concentrateur relai auquel est rattachée l'équipement et l'équipement, une requête d'autorisation de connexion. 9 Selon un sixième aspect de l'invention, l'invention concerne un procédé de transmission d'une commande entre un serveur d'administration et un dispositif compris dans un système de communication basé sur un système de gestion automatique de relevés de compteurs électriques, dit système AMM, le système AMM 5 comprenant au moins un concentrateur de données auquel sont rattachés des compteurs électriques intelligents, dit compteurs, via un premier réseau par courants porteurs en ligne, chaque concentrateur de données étant connecté à un système de gestion comprenant le serveur d'administration et une entité de gestion via un deuxième réseau et servant de relais entre lesdits compteurs et le système de gestion. 10 Le système de communication comprend un équipement, associé audit dispositif et connecté à un concentrateur de données, dit concentrateur relai, via un troisième réseau, l'équipement comprenant au moins une première interface de communication avec un premier quatrième réseau de type à grande portée et à faible consommation d'énergie, dit réseau de type LPWAN, ledit réseau de type LPWAN permettant à au 15 moins un dispositif connecté audit réseau de type LPWAN de communiquer avec l'équipement en utilisant un protocole propriétaire utilisant une couche physique identique à une couche physique utilisée par le protocole LoRaWAN et des trames comprenant une charge utile de niveau applicatif ayant un format propriétaire, et/ou au moins une deuxième interface de communication avec un deuxième quatrième réseau 20 de type filaire dans lequel chaque donnée ou commande transmise est transmise dans une trame conforme au protocole Modbus. Le procédé comprend transmettre une commande audit dispositif, par le serveur d'administration, via l'entité de gestion, le concentrateur relai auquel est rattaché l'équipement associé audit dispositif et l'équipement associé audit dispositif 25 Selon un septième aspect de l'invention, l'invention concerne un programme d'ordinateur, comprenant des instructions pour mettre en oeuvre, par un dispositif, le procédé selon le troisième aspect ou au moins une étape du procédé selon le quatrième le cinquième, ou le sixième aspect lorsque ledit programme est exécuté par un processeur dudit dispositif 30 Selon un huitième aspect de l'invention, l'invention concerne des moyens de stockage, stockant un programme d'ordinateur comprenant des instructions pour mettre en oeuvre, par un dispositif, le procédé selon le troisième aspect ou au moins une étape du procédé selon le quatrième, le cinquième ou le sixième aspect lorsque ledit programme est exécuté par un processeur dudit dispositif 10 Les caractéristiques de l'invention mentionnées ci-dessus, ainsi que d'autres, apparaîtront plus clairement à la lecture de la description suivante d'un exemple de réalisation, ladite description étant faite en relation avec les dessins joints, parmi lesquels : 5 - la Fig. 1 illustre schématiquement un exemple de système de communication par courants porteurs en ligne dans lequel est mise en oeuvre l'invention ; - la Fig. 2 illustre schématiquement un exemple d'architecture matérielle d'un module de traitement; - la Fig. 3 illustre schématiquement une trame de niveau physique selon 10 l'invention échangée entre un capteur ou un actionneur et une centrale de mesure selon l'invention ; - la Fig. 4A illustre schématiquement un premier exemple de charge utile d'une trame de niveau physique selon l'invention destinée à transporter des données ou des commandes; 15 - la Fig. 4B illustre schématiquement un deuxième exemple de charge utile d'une trame de niveau physique selon l'invention destinée à transporter une requête de connexion à un réseau; - la Fig. 4C illustre schématiquement un troisième exemple de charge utile d'une trame de niveau physique selon l'invention destinée à transporter une 20 autorisation de connexion à un réseau; - la Fig. 5 illustre schématiquement une charge utile de niveau MAC comprise dans la charge utile d'une trame de niveau physique selon l'invention; - la Fig. 6 illustre schématiquement une charge utile de niveau applicatif comprise dans la charge utile de niveau MAC ; 25 - la Fig. 7 illustre schématiquement un exemple de procédure de connexion à un réseau de type LPWAN permettant à une centrale de mesure et à un capteur ou un actionneur de communiquer ; - la Fig. 8 illustre schématiquement un exemple de procédure de transmission d'une commande à un actionneur ; et, 30 - la Fig. 9 illustre schématiquement un exemple de procédure de transmission de données émanant d'un capteur. L'invention est décrite dans un contexte de système de type AMM utilisé pour superviser un réseau BT dans lequel on souhaite insérer des dispositifs permettant une gestion intelligente dudit réseau BT. Les dispositifs décrits par la suite sont des 11 capteurs, tels que des capteurs de température, de pression ou de mouvement et des actionneurs. L'invention est aussi adaptée à d'autres contextes où l'insertion de dispositifs n'aurait pas pour objectif de permettre une gestion d'un réseau BT. Par exemple, l'invention pourrait permettre à des objets connectés qui ne seraient pas à 5 portée d'un réseau LPWAN tel qu'un réseau LoRa, de remonter de l'information vers un serveur de gestion par l'intermédiaire du réseau BT. La Fig. 1 illustre schématiquement un exemple de mise en oeuvre de l'invention dans un système de type AMM. Le système de type AMM de la Fig. 1 comporte une entité de gestion 130, aussi 10 appelée tête de système (« Head-end system » en terminologie anglo-saxonne) et une pluralité de compteurs 120. L'entité de gestion 130 est notamment en charge de collecter des informations transmises par les compteurs 120, telles que des informations de relevés de consommation électrique d'installations électriques que lesdits compteurs 120 sont en charge de surveiller. Pour permettre auxdits compteurs 15 120 de transmettre lesdites informations à l'entité de gestion 130, des communications CPL sont établies entre chacun desdits compteurs 120 et un concentrateur de données 110. Le système de communication comporte typiquement une pluralité de concentrateurs de données 110, un seul étant représenté sur la Fig. 1. A chaque concentrateur de données 110 est connecté, de manière logique, une pluralité de 20 compteurs 120, chaque concentrateur de données 110 servant ainsi de relais entre lesdits compteurs 120 qui lui sont connectés et l'entité de gestion 130. Un réseau CPL 101 est ainsi formé entre chaque concentrateur de données 110 et la pluralité de compteurs 120 qui lui est connectée. Ce réseau CPL 101 s'appuie sur un réseau de distribution électrique (i.e. réseau BT) 100 servant à alimenter en 25 électricité les installations électriques que lesdits compteurs 120 sont en charge de surveiller. Chaque compteur 120 comporte ainsi une interface 111 de communication CPL permettant de communiquer via le réseau CPL 101. De même, chaque concentrateur de données 110 comporte une telle interface 111 de communication CPL permettant de communiquer via le réseau CPL 101. Selon un exemple de 30 réalisation, le réseau CPL 101 est conforme au protocole G3-PLC. Selon un autre mode de réalisation, le réseau CPL 101 est conforme au protocole PRIME. Pour permettre de relayer les informations transmises par les compteurs 120 à destination de l'entité de gestion 130, chaque concentrateur de données 110 comporte en outre une interface 113 de communication avec un réseau de communication 102, 12 auquel est aussi connectée l'entité de gestion 130. Etant donné que les concentrateurs de données 110 peuvent être typiquement installés au sein de postes de transformation du réseau BT 100, le réseau de communication 102 est préférentiellement un réseau de télécommunication sans-fil. Selon un mode de réalisation, le réseau de communication 5 102 est conforme au standard UMTS (« Universal Mobile Telecommunications System » en terminologie anglo-saxonne). Selon un autre mode de réalisation, le réseau de communication 102 est conforme au standard LTE (« Long Term Evolution » en terminologie anglo-saxonne). L'entité de gestion 130 comporte ainsi une interface 113 de communication via 10 le réseau de communication 102 lui permettant de communiquer avec une pluralité de concentrateurs de données 110. L'entité de gestion 130 est préférentiellement conforme à l'ensemble de standards IEC 62056, i.e. aux spécifications DLMS (« Device Language Message Specification » en terminologie anglo-saxonne) et COSEM (« Companion Specification for Energy Metering » en terminologie anglo- 15 saxonne). Le système de communication de la Fig. 1 comprend de plus un serveur MDM (gestion de mesures de consommation électrique : « Meter Data Management (MDM) » en terminologie anglo-saxonne) 140. Le serveur MDM 140 reçoit les informations de mesure de consommation électrique collectées par l'entité de gestion 20 130 et les traite. Pour permettre au serveur MDM 140 de recevoir les informations de mesure de consommation électrique collectées par l'entité de gestion 130, le serveur MDM 140 et l'entité de gestion 130 comportent en outre une interface de communication 112A avec un réseau de communication 103. Le réseau de communication 103 est 25 préférentiellement un réseau de type IP (« Internet Protocol » en terminologie anglo- saxonne, tel que défini dans le document normatif RFC 791), tel que l'Internet. Dans un mode de réalisation, les communications entre l'entité de gestion 130 et le serveur MDM 140 utilisent des requêtes HTTP. Au moins un concentrateur de données 110 de système de type AMM de la Fig. 30 1 comporte une interface de communication 114 avec un réseau de communication 104 sur lequel est connectée par une même interface de communication 114 une unité 160 appelée centrale de mesure. Par la suite, chaque concentrateur de données 110 comportant une interface de communication 114 est appelé concentrateur relai. Un concentrateur de données est configure en concentrateur relai par exemple lorsqu'il se 13 situe dans une zone non couverte par un réseau LPWAN tel qu'un réseau LoRa. Une centrale de mesure 160 communiquant avec un concentrateur relai 110 est dite rattachée audit concentrateur relai 110. Dans un mode de réalisation, le réseau 104 est un réseau Ethernet (ISO/IEC 8802-3). La centrale de mesure 160 implémente un 5 serveur DLMS et le concentrateur relai 110 auquel elle est rattachée implémente un client DLMS. La centrale de mesure 160 comprend au moins une interface de communication 115A avec un réseau 105A de type LPWAN utilisant la même couche physique que les réseaux LoRa. Le réseau 105A permet à la centrale de mesure 160 de 10 communiquer avec au moins un dispositif 170A, chaque dispositif 170A étant connecté au réseau 105A par l'intermédiaire d'une interface de communication 115A. Dans la Fig. 1, seul un dispositif 170A est représenté. Le dispositif 170A peut être un capteur ou un actionneur. La centrale de mesure 160 et le dispositif 170A communiquent selon un protocole propriétaire similaire au protocole LoRaWAN que 15 nous décrivons par la suite en relation avec les Figs 3, 4A, 4B, 4C, 5 et 6. Dans un mode de réalisation, la centrale de mesure 160 comprend de plus une interface de communication 115B. L'interface de communication 115B permet à la centrale de mesure 160 de communiquer avec au moins dispositif 170B. Le dispositif 170B peut être un actionneur ou un capteur. Chaque dispositif 170B possède une 20 interface 115B. Chaque interface de communication 115B est connectée à un réseau de communication 105B filaire de type RS485. Dans la Fig. 1, seul un dispositif 170B est représenté. Le dispositif 170B communique avec la centrale de mesure 160 selon le protocole Modbus. Comme nous le verrons par la suite en relation avec la Fig. 7, la centrale de 25 mesure 160 reçoit des informations des dispositifs 170A, lorsque ces dispositifs sont des capteurs, et analyse ces informations. En fonction d'un résultat de cette analyse, la centrale de mesure 160 génère des alarmes si nécessaire et transmet chaque alarme générée à destination d'un serveur d'administration 150 compris dans le système de communication 1. Le serveur d'administration ou serveur ADMS (système de gestion 30 avancé de la distribution : « advanced distribution management system (ADMS) » en terminologie anglo-saxonne) 150 collecte les alarmes émanant de la centrale de mesure et les traite. Chaque transmission d'une alarme entre la centrale de mesure 160 et le serveur d'administration 150 se fait via le concentrateur relai 110 avec lequel la centrale de mesure 160 est rattachée et l'entité de gestion 130. Comme le serveur 14 MDM 140, le serveur d'administration 150 comporte une interface de communication 112A avec le réseau de communication 103. Les communications entre l'entité de gestion 130 et le serveur d'administration 150 utilisent par exemple des requêtes HTTP. 5 Par ailleurs, comme nous le décrivons par la suite en relation avec la Fig. 8, la centrale de mesure 160 relaie des commandes destinées aux dispositifs 170A ou 170B, lorsque ces dispositifs sont des actionneurs, émanant du serveur de gestion 150. Les commandes, lorsqu'elles sont destinées à un actionneur 170A sont appelées commandes propriétaires. Les commandes, lorsqu'elles sont destinées à un dispositif 10 170B de type actionneur sont conformes au protocole Modbus et sont appelées commandes Modbus. Chaque transmission d'une commande depuis le serveur d'administration 150 à destination des dispositifs 170A ou 170B de type actionneur se fait via l'entité de gestion 130 et le concentrateur relai 110 auquel est rattachée la centrale de mesure 160. 15 Une centrale de mesure 160 a donc des capacités accrues par rapport à une passerelle LoRa classique. En effet, chaque centrale de mesure 160 est non seulement capable de relayer des données entre un objet tel qu'un capteur ou un actionneur et un serveur d'administration 150, mais aussi d'analyser certaines données récoltées et de ne transmettre une alarme à destination du serveur d'administration 150 qu'en 20 fonction du résultat de l'analyse. Cette capacité d'analyse présente un intérêt important puisqu'elle limite un nombre de communications entre chaque centrale de mesure 160 et le serveur d'administration 150 au strict nécessaire. On réduit ainsi les risques de congestionner les réseaux impliqués dans les communications entre les dispositifs 170A et 170B et le serveur d'administration 150 (i.e. le réseau 103 et le 25 réseau 102). Dans un autre mode de réalisation, le réseau 104 est un réseau CPL. Dans un mode de réalisation, la centrale de mesure 160 rattachée à un concentrateur relai est intégrée dans le concentrateur relai 110. Chaque entité du système de la Fig. 1, que ce soit un concentrateur de données 30 110, un compteur 120, ou l'entité de gestion 130 comprend un module de traitement 20 (non représenté) permettant à ces entités de participer à une mise en oeuvre de l'invention. La Fig. 2 illustre schématiquement un exemple d'architecture matérielle du module de traitement 20. 15 Le module de traitement 20 comprend alors, reliés par un bus de communication 200: un processeur ou CPU 201 ; une mémoire vive RAM 202; une mémoire morte ROM 203 ; une unité de stockage ou un lecteur de support de stockage, tel qu'un lecteur de cartes SD 204 ; un ensemble d'interfaces de communication 205 permettant 5 au module de traitement 20 de communiquer avec d'autres entités du système de la Fig. 1. Lorsque le module de traitement 20 est compris dans un compteur 120, l'ensemble d'interfaces de communication 205 comprend l'interface de communication 111 vers le réseau CPL 101. 10 Lorsque le module de traitement 20 est compris dans un concentrateur de données 110, l'ensemble d'interfaces de communication 205 comprend l'interface de communication 111 vers le réseau CPL 101 et l'interface de communication 113 vers le réseau de communication 102. Lorsque le module de traitement 20 est compris dans un concentrateur de 15 données 110 qui fait office de concentrateur relai, l'ensemble d'interfaces de communication 205 comprend en outre l'interface de communication 114 vers le réseau 104. Lorsque le module de traitement 20 est compris dans l'entité de gestion 130, l'ensemble d'interfaces de communication 205 comprend l'interface de 20 communication 113 vers le réseau de communication 102, l'interface de communication 112A vers le réseau communication 103 et l'interface de communication 112B vers le réseau de communication 103. Lorsque le module de traitement 20 est compris dans le serveur MDM 140, l'ensemble d'interfaces de communication 205 comprend l'interface de 25 communication 112A vers le réseau 103. Lorsque le module de traitement 20 est compris dans le serveur d'administration 150, l'ensemble d'interfaces de communication 205 comprend l'interface de communication 112B vers le réseau 103. Lorsque le module de traitement 20 est compris dans la centrale de mesure 160, 30 l'ensemble d'interfaces de communication 205 comprend l'interface de communication 114 vers le réseau 104, au moins l'interface de communication 115A vers le réseau 105A et optionnellement l'interface de communication 115B vers le réseau de communication 105B. 16 Lorsque le module de traitement 20 est compris dans un dispositif 170A, l'ensemble d'interfaces de communication 205 comprend l'interface de communication 115A vers le réseau 105A. Lorsque le module de traitement 20 est compris dans un dispositif 170B de type 5 actionneur, l'ensemble d'interfaces de communication 205 comprend l'interface de communication 115B vers le réseau 105B. Le processeur 201 est capable d'exécuter des instructions chargées dans la RAM 202 à partir de la ROM 203, d'une mémoire externe (non représentée), d'un support de stockage, tel qu'une carte SD, ou d'un réseau de communication. Lorsque l'entité 10 (i.e. le concentrateur de données 110, un compteur 120, l'entité de gestion 130, le serveur MDM 140, le serveur d'administration 150, une centrale de mesure 160, un dispositif 170A, un dispositif 170B) est mise sous tension, le processeur 201 est capable de lire de la RAM 202 des instructions et de les exécuter. Ces instructions forment un programme d'ordinateur causant la mise en oeuvre, par le processeur 201 15 d'une partie du procédé décrit en relation avec les Figs. 7, 8 et 9 concernant ladite entité. Tout ou partie du procédé décrit en relation avec les Figs. 7, 8 et 9 peut être implémenté sous forme logicielle par exécution d'un ensemble d'instructions par une machine programmable, telle qu'un DSP (« Digital Signal Processor » en terminologie 20 anglo-saxonne) ou un microcontrôleur, ou être implémenté sous forme matérielle par une machine ou un composant dédié, tel qu'un FPGA (« Field-Programmable Gate Array » en terminologie anglo-saxonne) ou un ASIC (« Application-Specific Integrated Circuit » en terminologie anglo-saxonne). Les Figs. 3, 4A, 4B, 4C, 5 et 6 décrivent une syntaxe de trames de niveau 25 physique utilisée pour les trames échangées entre une centrale de mesure 160 et un dispositif 170A. La Fig. 3 illustre schématiquement une trame de niveau physique selon l'invention échangée entre un dispositif 170A et une centrale de mesure 160. La trame de niveau physique représentée en Fig. 3 est très similaire à une trame 30 de niveau physique conforme au protocole LoRaWAN. Ces trames sont utilisées sur le réseau 105A entre les dispositifs 170A et les centrales de mesure 160. La trame comprend en effet un champ preamble, un champ PDHR, un champ PHDR CRC et un champ CRC dont le format et la sémantique sont strictement identiques au format des champs portant le même nom dans le protocole LoRaWAN. Seul un champ 17 PHYPayload représentant une charge utile (« payload » en terminologie anglo-saxonne) de niveau physique de la trame diffère du champ de même nom dans le protocole LoRaWAN. Nous détaillons le champ PHYPayload en relation avec les Figs. 4A, 4B, 4C, 5 et 6. 5 La Fig. 4A illustre schématiquement un premier exemple de charge utile d'une trame de niveau physique selon l'invention destinée à transporter des données ou des commandes propriétaires. Dans l'exemple de la Fig. 4A, la charge utile d'une trame de niveau physique comprend un champ MHDR 330, un champ payload 331 et un champ M/C 332. Le 10 format et la sémantique des champs MHDR 330 et M/C 332 sont strictement identiques au format et à la sémantique des champs de même nom dans le protocole LoRaWAN. Le champ MHDR 330 est un entête de niveau MAC (contrôle d'accès au medium, « Medium Access Control » en terminologie anglo-saxonne) et comprend deux champs : un champ MTYPE et un champ RFU. Le champ RFU (« Reserved for 15 Future Use » en terminologie anglo-saxonne) est un champ réservé pour des utilisations futures. Le champ MTYPE indique le type de la trame. Des types de trames sont définis dans le protocole LoRaWAN sous forme de valeurs binaires à trois bits. Par exemple, la valeur binaire «000» correspond à une trame de demande de connexion (« Join Request » en terminologie anglo-saxonne). La valeur binaire «001 » 20 correspond à une trame d'autorisation de connexion (« Join Accept » en terminologie anglo-saxonne). La valeur binaire «111» est laissée libre pour permettre de définir une trame propriétaire. Dans le cadre de l'invention, la valeur binaire « 111 » est utilisée pour définir des trames permettant d'échanger des données ou des commandes propriétaires avec des capteurs. 25 Le champ payload 331 correspond à une charge utile de niveau MAC que nous détaillons par la suite en relation avec la Fig. 5. La Fig. 4B illustre schématiquement un deuxième exemple de charge utile d'une trame de niveau physique selon l'invention destinée à transporter une requête de connexion à un réseau. 30 Dans l'exemple de la Fig. 4B, la charge utile d'une trame de niveau physique comprend un champ MHDR 330, un champ Join-Request 334 et un champ M/C 332. Le Champ Join-Request 334 est identique au champ de même nom du protocole LoRaWan. On appellera par la suite une trame de niveau physique comprenant un 18 champ Join-Request 334 une requête de connexion. Lorsque le champ Join-Request 334 est présent dans une trame, le champ MTYPE prend la valeur binaire « 000 ». La Fig. 4C illustre schématiquement un troisième exemple de charge utile d'une trame de niveau physique selon l'invention destinée à transporter une autorisation de 5 connexion à un réseau. Dans l'exemple de la Fig. 4C, la charge utile d'une trame de niveau physique comprend un champ MHDR 330 et un champ Join-Accept 335. Le Champ Join-Accept 335 est identique au champ de même nom du protocole LoRaWan. On appellera par la suite une trame de niveau physique comprenant un champ Join-Accept 335 une 10 requête d'autorisation de connexion. Lorsque le champ Join-Accept 335 est présent dans une trame, le champ MTYPE prend la valeur binaire « 001 ». La Fig. 5 illustre schématiquement une charge utile de niveau MAC comprise dans la charge utile d'une trame de niveau physique selon l'invention. La charge utile de niveau MAC décrite en relation avec la Fig. 5 correspond au 15 champ payload 331 de la Fig. 4A. La charge utile de niveau MAC comprend un champ FHDR 3310 et un champ FRMPayload 3311. Le champ FHDR est identique au champ de même nom dans le protocole LoRaWAN. Le champ FRMPayload 3311 est un champ propriétaire. Lorsque le champ FRMPayload 3311 est présent dans une trame, le champ MTYPE prend la valeur binaire « 111 ». 20 La Fig. 6 illustre schématiquement une charge utile de niveau applicatif comprise dans la charge utile de niveau MAC. La charge utile de niveau applicatif correspond au champ FRMPayload 3311 de la Fig. 5. La charge utile de niveau applicatif comprend un champ DeviceType 33110 25 codé sur un octet, un champ CommandDataType 33111 codé sur un octet, un champ NumData 33112 codé sur un octet, et une suite de champs optionnels de un octet data 33113 destinés à recevoir des données à transmettre. Le champ DeviceType 33110 permet de définir un type de dispositif impliqué soit en tant que destinataire soit en tant qu'émetteur de la trame. Dans un mode de 30 réalisation, le champ Device Type 33110 prend la valeur « o» pour un actionneur et la valeur « 1» pour un capteur. Le champ CommandDataType 33111 permet de transporter une valeur représentative d'une commande lorsque le champ DeviceType 33110 est à «o », une valeur représentative d'un type de données lorsque le champ DeviceType 33110 est à 19 « 1» et une valeur représentative d'un accusé de réception, communément appelé ACK, que la valeur du champ DeviceType 33110 soit « o» ou « 1». Lorsque la commande est une fermeture, le champ CommandDataType 33111 prend la valeur « 0 ». 5 Lorsque la commande est une ouverture, le champ CommandDataType 33111 prend la valeur « 1». Lorsque la trame est un accusé de réception, le champ CommandDataType 33111 prend la valeur « 2». Lorsque le dispositif impliqué en tant que destinataire ou émetteur de la trame 10 est un capteur, le champ CommandDataType 33111 peut prendre une pluralité de valeurs comprenant les valeurs suivantes : - «3 » lorsque le capteur est un capteur de température. Les données transportées sont alors des données représentatives d'une température. - « 4 » lorsque le capteur est un capteur de pression. Les données 15 transportées sont alors des données représentatives d'une pression. - « 5 » lorsque le capteur est un capteur d'humidité. Les données transportées sont alors des données représentatives d'un taux d'humidité. - « 6 » lorsque le capteur est un capteur de mouvement. Les données transportées sont alors des données représentatives d'une amplitude de 20 mouvement. - « 7 » lorsque le capteur est un capteur de champ magnétique. Les données transportées sont alors des données représentatives d'une norme, d'une direction et d'un sens d'un champ magnétique. - « 8 » lorsque le capteur est un capteur de luminosité. Les données 25 transportées sont alors des données représentatives d'un niveau de luminosité. La pluralité de valeurs, et donc les types de capteurs, n'est pas limitative Le champ NumData 33112 indique combien d'octets de données sont présents dans la trame, i.e. combien de champs data 33113 sont présents dans la trame. Le 30 champ NumData 33112 prend la valeur « 0 » lorsque le dispositif concerné est un actionneur ou que la trame transporte un accusé de réception. Lorsque la trame transporte des données, le champ NumData 33112 prend une valeur supérieure ou égale à l'unité. 20 Une trame de niveau physique telle que décrite en relation avec la Fig. 3 comportant un champ FRAI-Payload 3311 dont le champ Device Type 33110 est à la valeur « o» et dont le champ CommandDataType 33111 est à la valeur « o» ou « 1» est une commande propriétaire. 5 Une trame de niveau physique telle que décrite en relation avec la Fig. 3 comportant un champ FRAI-Payload 3311 dont le champ Device Type 33110 est à la valeur « o» ou « 1» et dont le champ CommandDataType 33111 est à la valeur « 2» est appelée ACK propriétaire par la suite. Une trame de niveau physique telle que décrite en relation avec la Fig. 3 10 comportant un champ FRAI-Payload 3311 dont le champ Device Type 33110 est à la valeur « 1» et dont le champ CommandDataType 33111 est à la valeur « 3 » ou « 4 » ou « 5 » ou « 6» ou « 7» ou « 8 » mais dont le champ NumData 33112 est à la valeur « 0 » est appelée requête de données propriétaire par la suite. Une trame de niveau physique telle que décrite en relation avec la Fig. 3 15 comportant un champ FRAI-Payload 3311 dont le champ Device Type 33110 est à la valeur « 1», dont le champ CommandDataType 33111 est à la valeur «3 » ou « 4 » ou « 5 » ou « 6» ou « 7» ou « 8» et dont le champ NumData 33112 est à une valeur supérieure ou égale à l'unité est appelée paquet de données propriétaire par la suite. On note que les trames de niveau physique sont encryptées conformément au 20 protocole LoRaWAN. Chaque dispositif capteur ou actionneur possède des identifiants DevEUI et AppEUI (aussi appelé JoinEUD, des clés AppKey et NetSKey tels que définis dans le protocole LoRaWAN préprogrammés en usine. Comme dans un réseau LoRa classique dans lequel un objet connecté doit exécuter une procédure de connexion au réseau LoRa pour pouvoir communiquer sur 25 ledit réseau, chaque dispositif 170A doit exécuter une procédure de connexion au réseau de type LPWAN 105A pour pouvoir communiquer avec une centrale de mesure 160. La Fig. 7 illustre schématiquement un exemple de procédure de connexion au réseau de type LPWAN 105A permettant à la centrale de mesure 160 et au dispositif 30 170A de communiquer. Dans une étape 701, le dispositif 170A génère une requête de connexion telle que décrite en relation avec les Figs. 3 et 4B et émet cette requête de connexion en mode multidiffusion. 21 Chaque centrale de mesure 160 à portée du dispositif 170A reçoit cette requête de connexion, encapsule cette requête de connexion dans une trame conforme aux spécifications DLMS/COSEM, et transmet la trame ainsi formée au concentrateur relai 110 auquel est rattachée la centrale de mesure 160 dans une étape 702. 5 Dans une étape 703, chaque concentrateur relai 110 auquel est rattachée une centrale de mesure 160 ayant relayé la requête de connexion, reçoit une trame conforme aux spécifications DLMS/COSEM encapsulant la requête de connexion, et retransmet ladite trame à l'entité de gestion 130. Dans une étape 704, pour une même requête de connexion émanant d'un 10 dispositif 170A, l'entité de gestion 130 peut donc recevoir une pluralité de trames conformes aux spécifications DLMS/COSEM. L'entité de gestion 130 doit décider avec quelle centrale de mesure 160 le dispositif 170A doit être associé. Lorsqu'une seule centrale de mesure 160 a relayé la requête de connexion du dispositif 170A, l'entité de gestion 130 associe cette centrale de mesure 160 au dispositif 170A. Si 15 plusieurs centrales de mesure 160 ont relayé la requête de connexion du dispositif 170A, l'entité de gestion 103 choisit l'une de ces centrales de mesure 160, et associe la centrale de mesure 160 choisie au dispositif 170A. Dans un mode de réalisation, l'entité de gestion 103 choisit la centrale de mesure 160 aléatoirement parmi les centrales de mesure 160 ayant relayé la requête de connexion. 20 Dans une étape 705, l'entité de gestion 103 génère une requête d'autorisation de connexion destinée au dispositif 170A, encapsule cette requête dans une trame conforme aux spécifications DLMS/COSEM et transmet la requête ainsi encapsulée au concentrateur relai 110 auquel est rattachée la centrale de mesure 160 choisie par l'entité de gestion 103, dite centrale de mesure choisie. 25 Dans une étape 706, le concentrateur relai 110 auquel est rattachée la centrale de mesure 160 choisie reçoit la trame conforme aux spécifications DLMS/COSEM comprenant la requête d'autorisation de connexion et retransmet ladite trame à la centrale de mesure 160 choisie. Dans une étape 707, la centrale de mesure 160 choisie reçoit la trame conforme 30 aux spécifications DLMS/COSEM comprenant la requête d'autorisation de connexion, extrait la requête d'autorisation de connexion et transmet cette requête d'autorisation de connexion en point à point au capteur 170A. Dans une étape 708, le dispositif 170A reçoit la requête d'autorisation de connexion. 22 A la suite de cette procédure de connexion, le dispositif 170A ne communique qu'avec la centrale de mesure 160 choisie. Lorsque le dispositif 170A est un capteur, si des données remontées par le dispositif 170A déclenchent une alarme, cette alarme générée par la centrale de mesure 160 choisie est remontée vers le serveur 5 d'administration 150 via le concentrateur relai 110 auquel est rattachée la centrale de mesure 160 choisie. Dans le cas des dispositifs 170B, la procédure de connexion est quasiment identique. Dans ce cas toutefois, lorsqu'on rattache un dispositif 170B en Modbus à la centrale de mesure 160, un adressage de type Modbus est réalisé localement (entre la 10 centrale de mesure 160 et le ou les dispositifs 170B). Afin que l'entité de gestion 130 ait connaissance des dispositifs 170B connectés à la centrale de mesure 160, la centrale de mesure 160 fait passer chacun de ces dispositifs 170B pour un dispositif virtuel 170B'. Un dispositif virtuel 170B' est un logiciel exécuté par la centrale de mesure 160 implémentant chaque fonctionnalité et émulant un comportement d'un 15 dispositif 170B correspondant. La centrale de mesure 160 exécute ensuite les étapes 701, 702, 707 et 708 de la procédure de connexion décrite en relation avec la Fig. 7 pour chaque dispositif 170B. Dans la procédure de connexion de la Fig. 7, le dispositif 170A est remplacé par un dispositif virtuel 170B' créé par la centrale de mesure 160. Lors de l'étape 704, l'entité de gestion 130 ne peut donc recevoir qu'une seule trame 20 conforme aux spécifications DLMS/COSEM pour la requête de connexion émanant du dispositif virtuel 170B'. Il n'y a donc pas de choix de la centrale de mesure 160 à associer au dispositif virtuel 170B'. La centrale de mesure 160 associée au dispositif virtuel 170B' est nécessairement la centrale de mesure ayant créé le dispositif virtuel 170B'. L'exécution de la procédure de connexion permet à la centrale de mesure 160 25 de mettre en correspondance chaque dispositif virtuel 170B' avec le dispositif 170B correspondant. Lorsque le dispositif 170A est un actionneur, chaque commande propriétaire émanant du serveur d'administration 150 destinée au dispositif 170A transite par la centrale de mesure 160 choisie et par le concentrateur relai 110 auquel est rattachée la 30 centrale de mesure 160 choisie. La Fig. 8 illustre schématiquement un exemple de procédure de transmission d'une commande à un actionneur. 23 Chaque commande destinée à un actionneur est générée par le serveur d'administration 150. Dans la suite de la description de la Fig. 8, le dispositif 170A étant un actionneur, nous parlons d'actionneur 170A. Dans une étape 801, le serveur d'administration 150 génère une commande 5 propriétaire (respectivement Modbus) destinée à un actionneur 170A (respectivement 170B). Cette commande propriétaire ou Modbus est encapsulée dans une requête HTTP et transmise à l'entité de gestion 130. Dans une étape 802, l'entité de gestion 130 reçoit la requête HTTP, insère la commande propriétaire (respectivement Modbus) dans une trame conforme aux 10 spécifications DLMS/COSEM et transmet la trame à destination du concentrateur relai 110 auquel est rattachée la centrale de mesure 160 choisie pour l'actionneur 170A (respectivement 170B). Dans une étape 803, le concentrateur relai 110 reçoit la trame conforme aux spécifications DLMS/COSEM et retransmet ladite trame à destination de la centrale 15 de mesure 160 choisie. Dans une étape 804, la centrale de mesure 160 choisie reçoit la trame conforme aux spécifications DLMS/COSEM et transmet la commande propriétaire (respectivement Modbus) à l'actionneur 170A (respectivement 170B). Dans une étape 805, l'actionneur 170A (respectivement 170B) reçoit la 20 commande et lance une procédure d'exécution de la commande. Dans une étape 806, l'actionneur 170A (respectivement 170B) génère un ACK propriétaire (respectivement une trame d'accusé de réception conforme au protocole Modbus appelé par la suite ACK Modbus). L'ACK propriétaire (respectivement l'ACK Modbus) est transmis à la centrale de mesure 160 choisie associée à 25 1' actionneur 170A (respectivement 170B). Dans une étape 807, la centrale de mesure 160 reçoit l'ACK propriétaire (respectivement l'ACK Modbus), insère cet ACK propriétaire (respectivement cet ACK Modbus) dans une trame conforme aux spécifications DLMS/COSEM et transmet ladite trame au concentrateur relai 110 à laquelle est rattachée la centrale de 30 mesure 160 choisie. Dans une étape 808, le concentrateur relai 110 reçoit la trame conforme aux spécifications DLMS/COSEM et retransmet ladite trame à l'entité de gestion 130. Dans une étape 809, l'entité de gestion reçoit la trame conforme aux spécifications DLMS/COSEM, insère le ACK propriétaire (respectivement le ACK 24 Modbus) dans une requête HTTP et transmet la requête HTTP au serveur d'administration 150. Le serveur d'administration 150 sait alors que la commande propriétaire (respectivement Modbus) a été exécutée par l'actionneur 170A (respectivement 170B). 5 La Fig. 9 illustre schématiquement un exemple de procédure de transmission de données émanant d'un capteur. La procédure décrite en relation avec la Fig. 9 concerne les dispositifs 170A de type capteur, appelés capteurs 170A dans la suite de la description de la Fig. 9. Elle pourrait tout aussi bien s'appliquer aux dispositifs 170B de type capteur. 10 Dans une étape 901, la centrale de mesure 160 associée au capteur 170A transmet une requête de données propriétaire au capteur 170A. Dans une étape 902, le capteur 170A reçoit la requête de données propriétaire. Dans une étape 903, le capteur 170A transmet les données souhaitées à la centrale de mesure dans un paquet de données propriétaire. 15 Dans une étape 904, la centrale de mesure 160 reçoit le paquet de données propriétaire. Dans une étape 905, la centrale de mesure 160 vérifie que chaque valeur représentée par les données reçues est conforme à un critère prédéterminé dépendant du type des données transmises. Si chaque valeur est conforme au critère 20 prédéterminé, la centrale de mesure 160 décide de ne pas déclencher d'alarme lors d'une étape 906. Si au moins une valeur n'est pas conforme au critère prédéterminé, la centrale de mesure décide de déclencher une alarme lors d'une étape 907. Pour ce faire, lors de l'étape 907, la centrale de mesure 160 génère une requête représentative d'une alarme et transmet cette requête dans une trame conforme aux spécifications 25 DLMS/COSEM au concentrateur relai 110 auquel est rattachée la centrale de mesure 160. Dans un mode de réalisation, la requête représentative d'une alarme comporte une information représentative d'un type d'alarme. Une information représentative d'un type d'alarme donne par exemple le type de capteur ayant provoqué l'alarme. Dans une étape 908, le concentrateur relai 110 reçoit la trame conforme aux 30 spécifications DLMS/COSEM et retransmet cette trame à l'entité de gestion 130. Dans une étape 909, l'entité de gestion 130 reçoit la trame conforme aux spécifications DLMS/COSEM, insère la requête représentative d'une alarme dans une requête HTTP et transmet cette trame HTTP au serveur d'administration 150. 25 Dans un premier exemple, le capteur 170A est un capteur de température. Le critère prédéterminé dans ce cas est qu'aucune valeur de température mesurée par le capteur 170A (et reçue par la centrale de mesure 160) ne doit être en dehors d'un intervalle de valeurs comprises entre « -50 » degrés Celsius et « +100 » degrés 5 Celsius. Une alarme est déclenchée quand ce critère portant sur les valeurs de température n'est pas respecté. Une information représentative d'un type d'alarme dans ce cas est que l'alarme a été déclenchée par une valeur remontée par un capteur de température. Dans un deuxième exemple, le capteur 170A est un capteur de pression. Le 10 critère prédéterminé dans ce cas est qu'aucune valeur de pression mesurée par le capteur 170A (et reçue par la centrale de mesure 160) ne doit être supérieure à un bar. Une alarme est déclenchée quand ce critère portant sur les valeurs de pression n'est pas respecté. Une information représentative d'un type d'alarme dans ce cas est que l'alarme a été déclenchée par une valeur remontée par un capteur de pression. 15 Suite à la réception de cette alarme, le serveur d'administration peut déclencher une action, par exemple en envoyant une commande à un actionneur. Si par exemple, l'alarme a été déclenchée parce qu'un capteur de température placé à côté d'une installation électrique BT a remonté une valeur de température supérieure à « 100» degrés Celsius, le serveur d'administration transmet une 20 commande à un actionneur pour couper l'alimentation électrique de cette installation. Si par exemple, l'alarme a été déclenchée parce qu'un capteur de pression placé à côté d'une installation électrique BT a remonté une valeur de pression supérieure à un bar, le serveur d'administration transmet une commande à un actionneur pour couper l'alimentation électrique de cette installation. 25 Dans un mode de réalisation, l'étape 901 n'est pas exécutée. Les capteurs 170A décident d'eux mêmes de transmettre un paquet de données propriétaire, sans y être invité par la centrale de mesure 160. Dans un mode de réalisation, la centrale de mesure 160 ne déclenche une alarme que lorsqu'un nombre de capteurs 170A supérieur à un nombre de capteurs prédéfini 30 remontent à ladite centrale de mesure 160 une valeur non-conforme à un critère prédéterminé dépendant du type des données transmises. La procédure décrite en relation avec la Fig. 9 montre donc que toutes les données remontées par des capteurs 170A ne sont pas remontées par les centrales de mesure 160. Chaque centrale de mesure 160 ne transmet des informations liées aux 26 données qu'elle reçoit uniquement quand cela est nécessaire, c'est-à-dire, quand une alarme doit être déclenchée. On peut considérer que le procédé décrit en relation avec la Fig. 9 est un procédé de remontée d'alarme. On peut noter que l'entité de gestion 130 et le serveur d'administration 150 5 forment un système de gestion du réseau BT. Dans un mode de réalisation, l'entité de gestion 130, le serveur d'administration 150 et optionnellement le serveur MDM 140 sont intégrés dans une seule et même entité. Dans un mode de réalisation, les communications entre les dispositifs 170A et 10 les centrales de mesure 160, entre les centrales de mesure 160 et les concentrateurs relais 110, entre les concentrateurs relais 110 et l'entité de gestion 130 et entre l'entité de gestion 130 et le serveur d'administration REVENDICATIONS1) Equipement adapté pour être connecté à un système de gestion automatique de relevés de compteurs électriques, dit système AMM, le système AMM comprenant au moins un concentrateur de données (110) auquel sont rattachés des compteurs électriques intelligents (120), dits compteurs, via un premier réseau par courants porteurs en ligne (101), chaque concentrateur de données étant connecté à un système de gestion comprenant une entité de gestion (130) via un deuxième réseau (102) et servant de relais entre lesdits compteurs et le système de gestion, caractérisé en ce que: l'équipement est connecté à un concentrateur de données, dit concentrateur relai via un troisième réseau (104), ledit équipement comprend au moins une interface de communication (115A, 115B) avec un quatrième réseau (105A, 105B), ledit quatrième réseau permettant à au moins un dispositif connecté audit quatrième réseau de communiquer avec l'équipement, ledit équipement étant apte : à recevoir des données d'un ou plusieurs dispositifs connectés au quatrième réseau, à vérifier que les données reçues sont conformes à un critère prédéterminé dépendant d'un type des données transmises et de transmettre une alarme à un serveur d'administration (150) compris dans le système de gestion en cas de non-conformité desdites données ; et, apte à relayer une commande émise par le serveur d'administration et destinée à un dispositif connecté au quatrième réseau. 2) Equipement selon la revendication 1, caractérisé en ce que l'équipement comprend une première interface de communication (115A) avec un premier quatrième réseau (105A) de type à grande portée et à faible consommation d'énergie, dit réseau de type LPWAN, et/ou une seconde interface de communication (115B) avec un deuxième quatrième réseau (105B) de type filaire. 3) Système de communication basé sur un système de gestion automatique de relevés de compteurs électriques, dit système AMM, comprenant au moins un équipement selon la revendication 2. 28 4) Système selon la revendication 3, caractérisé en ce que chaque dispositif connecté au premier ou au deuxième quatrième réseau est un capteur ou un actionneur. 5 5) Système selon la revendication 4, caractérisé en ce le deuxième quatrième réseau est un réseau de type R5485 et chaque donnée ou commande transmise sur le deuxième quatrième réseau est transmise dans une trame conforme au protocole Modbus. 10 6) Système selon la revendication 4, caractérisé en ce que chaque donnée ou commande transmise sur le réseau de type LPWAN est transmise dans une trame conforme à un protocole propriétaire utilisant une couche physique identique à une couche physique utilisée par le protocole LoRaWAN et un format de charge utile de niveau applicatif propriétaire. 15 7) Système selon la revendication 6, caractérisé en ce que le format de charge utile propriétaire comprend un premier champ (33110) permettant de définir un type de dispositif impliqué soit en tant que destinataire soit en tant qu'émetteur de la trame, un deuxième champ (33111) permettant de transporter une valeur représentative d'une 20 commande lorsque la trame est destinée à un dispositif de type actionneur, une valeur représentative d'un type de données lorsque la trame est échangée avec un dispositif de type capteur ou une valeur représentative d'un accusé de réception, un troisième champ (33112) indiquant combien d'octets de données sont présents dans la charge utile de la trame et optionnellement, en fonction d'une valeur du troisième champ, un 25 ou plusieurs quatrièmes champs (33113) de données. 8) Système selon la revendication 6 ou 7, caractérisé en ce que le système est adapté pour exécuter une procédure de connexion lorsqu'un dispositif doit être connecté audit réseau de type LPWAN, la procédure de connexion comprenant : 30 émettre (701), par ledit dispositif, une requête de connexion conforme au protocole propriétaire en mode multidiffusion ; relayer (702), par chaque équipement dudit système ayant reçu ladite requête, ladite requête vers le concentrateur relai auquel est rattaché l'équipement ; 29 relayer (703), par chaque concentrateur relai auquel est rattaché un équipement ayant relayé la requête, ladite requête vers l'entité de gestion ; choisir (704), par l'entité de gestion, parmi les équipements ayant relayé ladite requête, un équipement à associer avec ledit dispositif ; 5 transmettre (705, 706, 707, 708) audit dispositif, par l'entité de gestion, via le concentrateur relai auquel est rattaché l'équipement choisi et l'équipement choisi, une requête d'autorisation de connexion. 9) Système selon la revendication 5, caractérisé en ce que, le système est adapté 10 pour exécuter une procédure de connexion lorsqu'un dispositif doit être connecté à un équipement par ledit deuxième quatrième réseau, la procédure de connexion comprenant : créer par ledit équipement, un dispositif virtuel représentant le dispositif devant être connecté au deuxième quatrième réseau ; 15 créer (701), par ledit dispositif virtuel, une requête de connexion conforme au protocole propriétaire; transmettre (702, 703, 704), par l'équipement, à l'entité de gestion, via le concentrateur relai rattaché à l'équipement, la requête de connexion ; transmettre (705, 706, 707, 708) audit dispositif virtuel, par l'entité de gestion, 20 via le concentrateur relai auquel est rattachée l'équipement et l'équipement, une requête d'autorisation de connexion. 10) Système selon la revendication 8 ou 9, caractérisé en ce que le système est adapté pour exécuter une procédure de transmission d'une commande à un dispositif 25 de type actionneur, la procédure de transmission d'une commande comprenant transmettre (801, 802, 803, 804, 805) une commande audit dispositif de type actionneur, par le serveur d'administration, via l'entité de gestion, le concentrateur relai auquel est rattaché l'équipement associé audit dispositif de type actionneur et l'équipement associé audit dispositif de type actionneur. 30 11) Système selon la revendication 10, caractérisé en ce que la procédure de transmission d'une commande comprend en outre, transmettre, par ledit dispositif de type actionneur un accusé de réception pour la commande au serveur d'administration, via l'équipement associé audit dispositif de type actionneur, le concentrateur relai 30 auquel est rattaché l'équipement associé audit dispositif de type actionneur et l'entité de gestion. 12) Système selon la revendication 8, caractérisé en ce que, le système est 5 adapté pour exécuter une procédure de transmission de données, la procédure de transmission de données comprenant, pour chaque dispositif de type capteur transmettant des données, transmettre (903), par ledit dispositif de type capteur, des données dans une trame conforme au protocole propriétaire à l'équipement associé audit dispositif de 10 type capteur, la transmission de l'alarme au serveur d'administration en cas de non- conformité de données reçues par un équipement se faisant via le concentrateur relai auquel est rattaché l'équipement ayant constaté ladite non-conformité. 13) Système selon la revendication 12, caractérisé en ce que la transmission par 15 ledit dispositif de type capteur des données dans une trame conforme au protocole propriétaire à l'équipement associé audit dispositif de type capteur fait suite à une réception par ledit dispositif de type capteur d'une requête (902) conforme au protocole propriétaire émise (901) par l'équipement demandant une transmission desdites données. 20 14) Procédé de remontée d'alarme exécuté par un équipement connecté à un système de communication basé sur un système de gestion automatique de relevés de compteurs électriques, dit système AMM, le système AMM comprenant au moins un concentrateur de données (110) auquel sont rattachés des compteurs électriques 25 intelligents (120), dits compteurs, via un premier réseau par courants porteurs en ligne (101), chaque concentrateur de données étant connecté à un système de gestion comprenant une entité de gestion (130) via un deuxième réseau (102) et servant de relais entre lesdits compteurs et le système de gestion, caractérisé en ce que : l'équipement est connecté à un concentrateur de données, dit concentrateur relai 30 via un troisième réseau (104) et comprend au moins une première interface de communication (115A) avec un premier quatrième réseau (105A) de type à grande portée et à faible consommation d'énergie, dit réseau de type LPWAN, ledit réseau de type LPWAN permettant à au moins un dispositif connecté audit réseau de type LPWAN de communiquer avec l'équipement en utilisant un protocole propriétaire 31 utilisant une couche physique identique à une couche physique utilisée par le protocole LoRaWAN et des trames comprenant une charge utile de niveau applicatif ayant un format propriétaire, et/ou au moins une deuxième interface de communication (115B) avec un 5 deuxième quatrième réseau (105B) de type filaire dans lequel chaque données ou commande transmise est transmise dans une trame conforme au protocole Modbus ; et, en ce que le procédé comprend : recevoir (904) d'un ou plusieurs dispositif de type capteur (170A, 170B) des données ; 10 vérifier (905) que les données reçues sont conformes à un critère prédéterminé dépendant d'un type des données transmises ; et, transmettre (907) une alarme à un serveur d'administration (150) compris dans le système de gestion en cas de non-conformité desdites données, la transmission se faisant via le concentrateur relai et l'entité de gestion. 15 15) Procédé de communication entre un dispositif et un serveur d'administration compris dans un système de communication basé sur un système de gestion automatique de relevés de compteurs électriques, dit système AMM, le système AMM comprenant au moins un concentrateur de données (110) auquel sont rattachés des 20 compteurs électriques intelligents (120), dits compteurs, via un premier réseau par courants porteurs en ligne (101), chaque concentrateur de données étant connecté à un système de gestion comprenant le serveur d'administration et une entité de gestion (130) via un deuxième réseau (102) et servant de relais entre lesdits compteurs et le système de gestion, caractérisé en ce que : 25 le système de communication comprend au moins un équipement connecté à un concentrateur de données, dit concentrateur relai via un troisième réseau (104), l'équipement comprenant au moins une interface de communication (115A) avec un quatrième réseau (105A) de type à grande portée et à faible consommation d'énergie, dit réseau de type LPWAN, ledit réseau de type LPWAN permettant à au moins un 30 dispositif connecté audit réseau de type LPWAN de communiquer avec l'équipement en utilisant un protocole propriétaire utilisant une couche physique identique à une couche physique utilisée par le protocole LoRaWAN et des trames comprenant une charge utile de niveau applicatif ayant un format propriétaire, et en ce que le procédé 32 comprend une procédure de connexion dudit dispositif audit quatrième réseau comprenant : émettre (701), par ledit dispositif, une requête de connexion conforme au protocole propriétaire en mode multidiffusion ; 5 relayer (702), par chaque équipement dudit système recevant ladite requête, ladite requête vers le concentrateur relai auquel est rattaché l'équipement ; relayer (703), par chaque concentrateur relai auquel est rattaché un équipement ayant relayé la requête, ladite requête vers l'entité de gestion ; choisir (704), par l'entité de gestion, parmi les équipements ayant relayé ladite 10 requête, un équipement à associer avec ledit dispositif ; transmettre (705, 706, 707, 708) audit dispositif, par l'entité de gestion, via le concentrateur relai auquel est rattaché l'équipement choisi et l'équipement choisi, une requête d'autorisation de connexion. 15 16) Procédé de communication entre un dispositif et un serveur d'administration compris dans un système de communication basé sur un système de gestion automatique de relevés de compteurs électriques, dit système AMM, le système AMM comprenant au moins un concentrateur de données (110) auquel sont rattachés des compteurs électriques intelligents (120), dits compteurs, via un premier réseau par 20 courants porteurs en ligne (101), chaque concentrateur de données étant connecté à un système de gestion comprenant le serveur d'administration et une entité de gestion (130) via un deuxième réseau (102) et servant de relais entre lesdits compteurs et le système de gestion, caractérisé en ce que : le système de communication comprend au moins un équipement connecté à un 25 concentrateur de données, dit concentrateur relai via un troisième réseau (104), l'équipement comprenant au moins une interface de communication (115B) avec un quatrième réseau (105B) de type filaire dans lequel chaque donnée ou commande transmise est transmise dans une trame conforme au protocole Modbus, et en ce que le procédé comprend une procédure de connexion dudit dispositif audit quatrième réseau 30 comprenant : créer par ledit équipement, un dispositif virtuel représentant le dispositif devant être connecté au quatrième réseau ; créer (701), par ledit dispositif virtuel, une requête de connexion conforme au protocole propriétaire; 33 transmettre (702, 703, 704), par l'équipement, à l'entité de gestion, via le concentrateur relai rattaché à l'équipement, la requête de connexion ; transmettre (705, 706, 707, 708) audit dispositif virtuel, par l'entité de gestion, via le concentrateur relai auquel est rattachée l'équipement et l'équipement, une 5 requête d'autorisation de connexion. 17) Procédé de transmission d'une commande entre un serveur d'administration et un dispositif compris dans un système de communication basé sur un système de gestion automatique de relevés de compteurs électriques, dit système AMM, le 10 système AMM comprenant au moins un concentrateur de données (110) auquel sont rattachés des compteurs électriques intelligents (120), dits compteurs, via un premier réseau par courants porteurs en ligne (101), chaque concentrateur de données étant connecté à un système de gestion comprenant le serveur d'administration et une entité de gestion (130) via un deuxième réseau (102) et servant de relais entre lesdits 15 compteurs et le système de gestion, caractérisé en ce que : le système de communication comprend un équipement, associé audit dispositif et connecté à un concentrateur de données, dit concentrateur relai, via un troisième réseau (104), l'équipement comprenant au moins une première interface de communication (115A) avec un premier quatrième réseau (105A) de type à grande 20 portée et à faible consommation d'énergie, dit réseau de type LPWAN, ledit réseau de type LPWAN permettant à au moins un dispositif connecté audit réseau de type LPWAN de communiquer avec l'équipement en utilisant un protocole propriétaire utilisant une couche physique identique à une couche physique utilisée par le protocole LoRaWAN et des trames comprenant une charge utile de niveau applicatif 25 ayant un format propriétaire, et/ou au moins une deuxième interface de communication (115B) avec un deuxième quatrième réseau (105B) de type filaire dans lequel chaque données ou commande transmise est transmise dans une trame conforme au protocole Modbus et en ce que le procédé comprend transmettre (801, 802, 803, 804, 805) une 30 commande audit dispositif, par le serveur d'administration, via l'entité de gestion, le concentrateur relai auquel est rattaché l'équipement associé audit dispositif et l'équipement associé audit dispositif 34 18) Programme d'ordinateur, caractérisé en ce qu'il comprend des instructions pour mettre en oeuvre, par un dispositif, le procédé selon la revendication 14 ou au moins une étape du procédé selon la revendication 15, 16 ou 17 lorsque ledit programme est exécuté par un processeur dudit dispositif 5 19) Moyens de stockage, caractérisés en ce qu'ils stockent un programme d'ordinateur comprenant des instructions pour mettre en oeuvre, par un dispositif, le procédé selon la revendication 14 ou au moins une étape du procédé selon la revendication 15, 16 ou 17 lorsque ledit programme est exécuté par un processeur 10 dudit dispositif