L'expérience de l'utilisation de LoRaWAN dans le système ASKUE en conditions réelles de la ville

Cet article présente les résultats de l'opération pilote d'un système de comptage d'appartements commerciaux de ressources énergétiques (ci-après ASKUE) en conditions réelles de la ville basé sur des équipements domestiques LoRaWAN.

Depuis 2010, notre entreprise crée des systèmes de comptabilité commerciale et technique dans le logement et les services communaux. Nous utilisons depuis longtemps et avec succès les canaux et équipements de communication «classiques» pour créer des systèmes comptables. L'un des projets phares de l'entreprise a été la création du plus grand système à l'époque de la Fédération de Russie de logements commerciaux et de locations d'appartements représentant 1200 immeubles d'appartements dans la ville de Saransk en 2014.

Début 2017, nous avons activement commencé à rechercher les technologies LPWAN et IoT. L'une des directions du développement de l'IoT est les modems radio à très faible puissance, qui permettent aux appareils IoT de fonctionner de manière autonome pendant plusieurs années à partir de la batterie et de transmettre des données sur des distances relativement longues. Les principales technologies dans ce domaine sont LoRaWAN et NB-IoT. Et si la norme NB-IoT est encore au stade de zones de couverture pilote pour les opérateurs mobiles, alors l'équipement LoRaWAN est déjà produit en série et déployé en Russie. C'est avec LoRaWAN que nous avons décidé de procéder à des essais et, en cas de tests réussis, d'introduire cette technologie.

Qu'avons-nous aimé de la technologie LoRaWAN?

• Premièrement, la distance de transmission radio déclarée est 10 fois plus longue que les autres technologies sans fil utilisées pour la télémétrie (RF433, ZigBee, Z-Wave), ce qui permet en pratique de réduire le nombre de stations de base.
• Deuxièmement, la technologie permet l'installation de modems radio de faible puissance alimentés par des batteries sur des appareils de mesure et des capteurs, tandis que la durée de vie des batteries des appareils sera de 5 à 10 ans. Par exemple, les compteurs d'eau des appartements ont toujours été un problème pour nous lors de la connexion. Et dans le cas de LoRaWAN, vous pouvez organiser la collecte de données dans la salle de bain de l'appartement sans gâcher la réparation, sans sommer les lignes de signal et d'alimentation. De plus, les piles, dans le cas de LoRaWAN, dureront jusqu'au prochain remplacement du compteur.
• Troisièmement, l'utilisation de leurs propres stations de base et fréquences non autorisées. Le transfert de données est gratuit, contrairement à l'utilisation du GSM et de son incarnation NB-IoT.

Énoncé du problème et description du système de comptabilité de test

Nous voulions donc vérifier le fonctionnement des équipements LoRaWAN. Dans un sens, nous avons eu la chance de rencontrer immédiatement des collègues de la société Novosibirsk Vega Absolute lors de la conférence IoT. Après une petite étude des solutions disponibles début 2017, nous avons réalisé que soit des équipements occidentaux sont disponibles, soit ce que fait Vega Absolute et plusieurs startups. L'équipement «Vega-Absolute» a été sélectionné et les objectifs de l'opération pilote ont été formulés. Nous avons décidé de le tenir à Penza.

Nous avons utilisé:

• Modems SI-13-485 pour fonctionnement RS485 en mode «canal transparent»;
• Modems avec compteurs d'impulsions Vega SI-11;
• Station de base Vega BS-1;

Les tâches de l'opération d'essai ont été formulées comme suit:

1. Tester l'échange d'informations avec un compteur «en marche» pour la mesure de l'électricité via RS-485 via le modem radio SI-13-485, étudier les caractéristiques de l'enquête;
2. Construire un système de comptage avec des compteurs d'appartement pour l'électricité et l'eau et mener des opérations d'essai à long terme en milieu urbain.

L'architecture du système comptable ressemblait à ceci:

Échange d'informations avec le compteur électrique Mercury-206 via RS-485 via le "canal de communication transparent"

Le support suivant a été utilisé pour les tests:

• Serveur ASKUE qui se connecte au serveur LoRaWAN IOT Vega;
• Équipement de formation de canaux de la station de base (BS) LoRaWAN - modem SI-13-485;
• Compteur électrique Mercury-206 PLNO (connexion via RS485).

Pour organiser un canal de communication transparent sur le banc d'essai, un logiciel spécial a été installé et configuré qui organise un "canal transparent" de communication avec l'appareil connecté via le canal radio LoRaWAN. L'analyse du trafic a montré que l'échange avec l'appareil est très lent, en règle générale, la réponse de l'appareil s'accompagne d'un retard de 11 secondes. Avec un tel retard, la durée totale de scrutation de l'appareil dépend en grande partie du nombre de paramètres du compteur étudié, cela est dû aux caractéristiques du protocole d'échange LoRaWAN (combien de paramètres du compteur peuvent être obtenus par demande) et à la nécessité de lire les données historiques à partir des archives du compteur.

Ainsi, lors de la lecture de 15 paramètres opérationnels de l'instrument Mercury-206, la période totale de mise à jour des données était en moyenne de 70 secondes, cependant, la période d'interrogation finale dépend fortement de l'ensemble de paramètres (balises) sélectionné et, dans le pire des cas, la période d'interrogation pour 15 balises était de 160 secondes.

Lors de la lecture des données historiques, le temps de réception d'une archive quotidienne d'énergie active à un point de mesure pour le tarif était de 11 secondes, la vitesse d'obtention du profil de puissance était de 48 "demi-heures" toutes les 70 secondes.

De plus, pour analyser la stabilité de l'échange, une longue période de 3 jours a été organisée, au cours de laquelle une étude continue des paramètres du compteur connecté a été réalisée afin d'identifier d'éventuels problèmes. En conséquence, il y avait des problèmes avec l'enquête et on nous a recommandé de mener une enquête beaucoup moins fréquemment. Par conséquent, l'interrogation des paramètres du périphérique par le pilote a été configurée pour interroger une fois toutes les 1 heure et a fonctionné pendant 5 jours. Au cours de cette période, une relation relativement stable a été observée (environ 0 à 3 pauses par jour). En même temps, pendant l'exécution, une réception unique de données incorrectes sur un paramètre a été enregistrée. Cela est probablement dû à la confusion des paquets de réponse de l'appareil (dans le protocole d'échange Mercury 206, il n'y a aucune possibilité de valider le paquet de réponse).

Les conclusions suivantes peuvent être tirées des résultats des tests:

1. Compte tenu des retards importants dans le canal de communication, l'échange d'informations avec les appareils ne devrait pas être effectué souvent; pour les tâches de répartition, la technologie testée pour l'interrogation via un canal transparent et avec les protocoles de communication standard du panneau de commande n'est pas applicable.
2. Lors de la configuration de la lecture des archives, il n'est pas recommandé d'interroger les archives de l'instrument qui supposent une grande quantité de données (profils de puissance, etc.).

En outre, sur la base de notre expérience avec les protocoles d'autres appareils de mesure, les retards observés dans le canal transparent LoRaWAN - RS-485 peuvent rendre impossible la lecture des archives de certains autres types d'appareils (compteurs de chaleur TEM-106, TEM-104, lecture des profils de puissance avec Mercury 230 et quelques autres).

Ces tests ont donné des résultats théoriquement attendus et ont clairement démontré pourquoi les dispositifs IOT s'éloignaient du mode réponse-demande, classique pour les systèmes AMR, et passaient au mode d'interrogation côté compteur intelligent et envoyaient de manière proactive les données du panneau de commande au serveur selon un calendrier ou un événement.

Tests d'un système de collecte de données à partir d'appareils de mesure à sortie impulsionnelle

L'expérience a été menée dans les installations de Penza. Les objectifs de l'expérience étaient:

1. Détermination de la zone de couverture réelle d'une station de base dans des conditions urbaines et dans des zones ouvertes (banlieues);
2. Vérification du niveau du signal à l'intérieur des immeubles d'habitation dans la zone de couverture (effet des murs et des cloisons sur le niveau du signal);
3. Sélection de l'antenne et du site d'installation de l'antenne de la station de base, détermination de l'effet de l'antenne sur la couverture et le niveau du signal.

Première étape. Vérifié la zone de couverture extérieure avec une antenne de 4,5 dBi

Notre service d'implémentation a installé la station de base Vega BS-1 et une antenne de 4,5 dBi, qui, à l'époque, étaient fournies avec la BS. Nous avons effectué un test préliminaire de la zone de couverture extérieure. La carte ci-dessous montre les résultats de notre premier test: le vert indique la réception réussie d'un signal BS, le rouge - non.



Conclusions: La zone de couverture avec l'antenne complète est loin du maximum pour LoRaWAN et, dans notre cas, était de 2 km. Il est devenu clair que nous devons aborder soigneusement l'installation de la station de base, les 10 km réclamés sans une bonne antenne et une planification radio minimale, même dans les zones ouvertes, ne peuvent pas être obtenus.

Deuxième étape. Vérification de la zone de couverture à l'intérieur des bâtiments avec une antenne de 4,5 dBi

Sur la même installation BS, ils ont décidé de vérifier immédiatement le fonctionnement du compteur d'impulsions Vega SI-11 à l'intérieur d'un immeuble résidentiel à une distance de 422 mètres de la BS. Les points de mesure se trouvaient à l'intérieur de l'immeuble, au 1er étage. Nous en attendions un autre, mais des tests ont montré qu'il n'y a pas de signal de réception!

Contacté ceux-ci. Prise en charge de Vega, mise à jour du logiciel, mais la connexion n'a pas pu être établie. Réalisation d'une analyse des résultats et re-testée dans les emplacements d'installation proposés des appareils. Enfin, il a été possible d'obtenir le transfert des colis d'un endroit non couvert par le mur de la capitale de la direction à la BS. En conséquence, nous avons réussi à obtenir un résultat positif et le transfert de paquets a réussi. De plus, nous avons placé le SI-11 directement au premier étage de la même maison avec un BS installé sur le toit, la transmission de paquets a également réussi (bien qu'il ne soit pas recommandé de placer des modems sous le BS).



Conclusions des résultats de la deuxième étape: vous pouvez utiliser la solution existante lors de la prise de données dans le même MCD où le BS est installé, ainsi que dans le MCD et les objets situés dans un rayon de 300 à 400 m du site d'installation du BS, mais dans chaque cas, des tests préliminaires de la couverture radio . De plus, il n'est pas recommandé d'installer des modems derrière un mur principal de plus de 500 mm en direction du BS.

Les résultats étaient clairement inférieurs à nos attentes, nous avons tenu des consultations avec les experts de Vega et sommes arrivés à la conclusion évidente maintenant: nous avons besoin d'une bonne antenne BS avec un gain élevé, nous devons correctement monter la BS loin de la BS des opérateurs cellulaires et d'autres interférences, la placer correctement sur le toit et répéter les tests.

Test de troisième phase avec antenne 10 dBi

Ils ont installé une nouvelle antenne 10 dBi de la société moscovite Radial à 868 MHz, le site d'installation du BS est sur le toit d'un immeuble de 12 étages. Malheureusement, «la vie a fait des ajustements» et nous avons été autorisés à installer une antenne et un BS sur le toit de la maison à la fin de ceux-ci. construire des bâtiments de cette manière uniquement:



D'un autre côté, la direction vers les points de mesure dans les maisons testées ne chevauchait pas cette technologie. par construction. Ensuite, nous avons testé la gamme de communication dans une ville en dehors des locaux. Les modems ont été utilisés dans le mode d'émulation d'envoi d'impulsions, sans connecter le panneau de commande. À une distance allant jusqu'à 6 km de la BS, les paquets ont réussi, ainsi, la distance maximale pouvant être obtenue à l'extérieur était de 6 km:



Ainsi, nous pouvons nous attendre à une transmission du signal à partir de modems situés, par exemple, dans le secteur privé, à une distance maximale de 5-6 km d'un BS avec une antenne de 10 dBi située sur le toit d'un MKD de 10 à 12 étages.

Tests à long terme et statistiques sur les paquets

Ensuite, nous avons effectué un test à long terme avec la collecte de statistiques sur le passage des paquets de compteurs d'impulsions SI-11 avec PU Mercury. Le test a impliqué 4 points de mesure (679 m, 422 m, 243 m, 126 m du BS), comme indiqué ci-dessous:



Notez qu'à un point situé à une distance de 422 m derrière le mur principal de 600 mm, dans lequel il n'y avait pas de communication avec l'antenne 4,5 dBi auparavant, une connexion est apparue avec la nouvelle antenne 10 dBi, mais avec une perte de paquets de 10%. Ainsi, dans un rayon d'environ 700 m, le niveau du signal est assez élevé (RSSI ~ 115), ce qui vous permet d'installer des modems dans cette zone à l'intérieur du MKD et de transmettre de manière fiable des données.

La photo ci-dessous montre un emplacement d'installation typique d'un appareil de mesure sur un escalier dans un écran de plancher pour des appareils de mesure EE auxquels un modem est connecté:



Affichage des données du compteur Energomera CE101 dans le système. La transmission des données s'effectue via le modem SI-11-1. Le graphique présente des données sur l'énergie active (D, H):



Pour la période de test initiale, d'une durée de 144 heures, avec la transmission de paquets une fois par heure en février 2018, les statistiques suivantes sur la transmission des données ont été obtenues:

• le nombre de colis reçus avec succès est de 132 sur 144, soit 91,6%;
• le nombre de tentatives infructueuses - 12, dont par erreur:
• TOO_LARGE_GW_PING_ERR (ping trop grand pour la BS) - 8 pièces;
• LATENCY_ERR (délai du serveur BS) - 4 pièces.

Si vous regardez les statistiques pendant une période plus longue du 21/02/2018 au 18/03/2018, 142 paquets sur 624 ~ 23% avec les paramètres de modem par défaut ont été perdus. À cet égard, le paramètre du modem «Nombre de nouvelles tentatives de paquets» a été augmenté à 5 (c'est-à-dire que le modem enverra le paquet tant de fois jusqu'à ce qu'il reçoive la confirmation de la station de base). En conséquence, la perte de paquets a été presque complètement éliminée. Nous pensons que ce paramètre doit être réglé de 3 à 5, en fonction des exigences de consommation de la batterie.

Test du taux de décharge de l'alimentation électrique intégrée des compteurs d'impulsions LoRaWAN SI-11

En trois mois, les éléments d'alimentation intégrés des modems SI-11 ont été testés:

Période de test: 19/03/2018 - 06/07/2018 (près de 3 mois):

1. Conditions de test: les modems sont installés dans des panneaux sur l'escalier MKD, température positive constante (selon le capteur de température à l'intérieur du modem de +26 à +29 ° C);
2. Fréquence d'interrogation: SI-11 n ° 383336384B368A0F - 1 fois par heure, SI-11 n ° 3530373550376114 - une fois toutes les 6 heures.

Tableau avec des données sur la charge restante de la batterie:



Conclusions: compte tenu des résultats obtenus, on peut estimer le temps de fonctionnement dans des conditions similaires jusqu'à 100% de décharge de la batterie:

• pendant l'enquête 1 fois par heure - 45 mois ou 3,7 ans
• interrogé une fois toutes les 6 heures - 135 mois ou 11,2 ans

Conclusions générales des résultats des tests

La technologie "fonctionne". L'équipement pour l'été 2018 est déjà disponible dans le commerce dans la gamme de la production nationale. La technologie doit être appliquée en tenant compte de ses caractéristiques:

1. L'équipement LoRaWAN fonctionne de manière fiable dans un rayon de 1 km du BS à l'intérieur des bâtiments et jusqu'à 5-6 km à l'extérieur s'il est «correctement préparé»;
2. fonctionne très bien avec des appareils spécialement conçus pour LoRaWAN et fonctionne mal (lentement) en mode de canal transparent RS-485 en raison de retards de canal importants;
3. Il nécessite cependant l'installation compétente d'un BS, comme tout équipement de radiocommunication. Un placement BS correct et une bonne antenne sont la clé du succès;
4. les 6 à 10 ans d'autonomie revendiqués sont tout à fait réalisables avec le bon réglage pour la fréquence de collecte des données.
5. la technologie est idéale pour une installation à l'intérieur des appartements pour tenir compte de l'eau chaude et de l'approvisionnement en eau chaude, ainsi que de l'efficacité énergétique, mais il existe une alternative sous la forme d'un PLC