Notes du fournisseur IoT. LoRaWAN et RS-485

Bonjour chers amoureux de l'Internet des objets. Je continue ma série d'articles.

Nous avons donc appris à travailler avec la sortie d'impulsions des compteurs et le cryptage maîtrisé. Quelle est la prochaine étape? La réponse est évidente. RS-485.

Un peu de théorie. RS-485 (norme recommandée) est une interface de couche physique asynchrone. Il a acquis une immense popularité sur l'Internet industriel, allant des services publics et se terminant par diverses usines et entreprises.

En principe, presque tout compteur qui veut nous donner non pas un, mais plusieurs paramètres, très probablement, sera équipé de RS-485. Plus rarement, RS-232 ou M-Bus, mais pour l'instant laissons-les de côté et analysons l'exemple le plus révélateur. Plus précisément, des problèmes pour travailler avec lui.

Problème de vitesse

RS-485 est une norme filaire. LoRa - sans fil. Il est logique qu'il doit y avoir un certain appareil capable de se lier d'amitié avec eux.

D'accord. Presque tous les fabricants du terminal de la ligne disposent d'un module radio avec prise en charge RS-485. Il fonctionne sur le principe d'un canal transparent. Tous les paquets qui transitent par le câble sont emballés comme une charge utile de paquets LoRaWAN et envoyés à la transmission. Ou sont reçus et convertis en impulsions électriques.

Et voici le premier problème. RS-485 est une interface à très haut débit. Les paquets y vont à des vitesses de plusieurs kilobits / sec ou même de plusieurs dizaines. Par exemple, l'une des vitesses Modbus typiques est de 9,6 kbit / s.

LoRa, même avec le meilleur SF = 7 (125 kHz, 4/5), compressera 5,5 kbit / s. Avec un SF plus élevé, il y en aura encore moins.

Cela signifie que le relevé des valeurs de certains compteurs électriques ne prendra pas des secondes, ni même des dizaines de secondes. Le score durera quelques minutes. Et cela avec un temps d'attente correctement ajusté. Si vous laissez les paramètres par défaut, votre enquête se terminera très probablement par une erreur de temporisation. Je ne parle pas des restrictions sur la longueur des paquets LoRaWAN. Il y a juste des ennuis.

Problème de sondage

Avec les sorties impulsions, tout est simple. Nous comptons les impulsions, les multiplions par le prix de division et obtenons la lecture du compteur. Toute interface simple peut gérer cela. Et une telle interface, en plus de la simplicité, sera plus universelle.

Avec RS-485, tout est bien pire. Étonnamment, beaucoup ne comprennent pas une chose importante.
RS-485 N'EST PAS UN PROTOCOLE D'ÉCHANGE! Il ne spécifie pas le format des paquets qui y entrent. En fait, ce n'est qu'un moyen de transmission. Seules les caractéristiques électriques et temporelles de l'interface sont spécifiées. C’est tout! Tout sur le dessus doit déjà être démonté séparément.

Et il y a quelque chose à démonter! En plus de notre environnement, chaque fabricant peut réaliser ce qu'il veut. Eh bien, ou ce qui s'est avéré être pratique pour lui personnellement. Par exemple, le compteur de chaleur VKT-7 communiquera avec nous via ModBus. Et Energomera - grâce à GOST R IEC 61107-2001.

Ce sont tous des protocoles qui se superposent au support de transmission par le haut et ont un niveau supérieur. Chaque protocole a sa propre composition de la trame, nécessite ses propres équipes pour effectuer certaines actions, prévoit un stockage différent (et donc une interrogation) des valeurs. Par conséquent, chaque périphérique a besoin de son propre script d'interrogation. De plus, même dans le cadre d'un protocole (le même ModBus), ce script sera différent d'un appareil à l'autre.

Les protocoles eux-mêmes ne sont pas un secret et, pour la plupart, sont ouverts. De plus, le site Web de chaque fabricant contient souvent un utilitaire gratuit avec lequel vous pouvez interroger les appareils. Mais ces utilitaires ne sont pas universels et aiguisés pour un seul fabricant. Et nous nous souvenons que nous avons presque toujours un zoo d'appareils. Et pour mettre plusieurs programmes sur le client en même temps ... eh bien, ce n'est pas trop pratique.

Il existe deux solutions. Ou écrivez quelque chose de vous-même. Ou prenez un programme dans lequel des scripts d'interrogation pour les appareils les plus populaires ont déjà été compilés. Il existe de nombreuses solutions prêtes à l'emploi sur le marché, par exemple, «LERS-accounting» ou «YaEnergetik». Mais ils sont payés et coûtent cher. Ainsi que le développement de son logiciel.

De plus, si nous parlons d'Internet industriel (c'est-à-dire que nous allons au-delà du cadre du logement et des services communaux), des solutions universelles prêtes à l'emploi ne vous aideront plus. Comment être

Pas question.

Si vous prévoyez toujours d'interroger LoRa via un canal transparent, vous rencontrerez toujours des limites de vitesse et des délais d'attente. Ce n'est peut-être pas immédiatement et pas avec le premier appareil, mais cela se produira.

Problème standard

En plus de tous les ennuis, nous en avons un de plus. Parce que RS-485 implique que nous pouvons contacter l'appareil à tout moment, le module radio LoRa avec son support doit être de classe C. C'est-à-dire, toujours écouter la diffusion et être prêt à répondre.

Permettez-moi de vous rappeler que la classe C n'implique pas la puissance de la batterie, mais le problème n'est pas si grave. En règle générale, le RS-485 est l'endroit où une alimentation externe peut être obtenue.

Le pire est un autre.

Selon la loi, nous pouvons fonctionner dans deux gammes de fréquences. Rappelez-vous la limite de 864-865 MHz? Pas plus de 0,1% du temps en ondes? Cela signifie que chaque appareil pris séparément peut être en ondes, par exemple, pas plus de 3,6 secondes par heure. Mais pendant ce temps, à SF = 12, nous ne poussons même pas trois packages.

Vous pouvez essayer d'extraire le maximum des canaux 868.7-869.2. Cependant, une autre restriction des normes régionales de spécification LoRaWAN entre en vigueur ici - pas plus de 1% du temps d'antenne pour chaque appareil terminal (cycle de service). OK, déjà plus facile, 36 secondes. Seul le sens n'est toujours pas vraiment.

À un moment donné, nous pouvons dire - eh bien eux, ces bêtises! Je resterai en l'air aussi longtemps que nécessaire! Mais alors il apparaît:

Problème de capacité en éther

LoRa n'échange pas en vain des paquets courts et rares. En fait, toute la norme est construite autour de cela. Il faut que chaque appareil prenne le moins de temps possible à l'antenne. Ensuite, nous réduirons le risque de collisions et serons en mesure d'atteindre cette fantastique densité de plusieurs milliers de radimodules par BS. Que se passera-t-il si un module radio griffonne en paquets comme une mitrailleuse? Sa fréquence est occupée au moment de la transmission. Et au moment de la réponse, toutes les fréquences sont occupées, car la station de base n'entend rien lorsqu'elle se transmet.

Bien sûr, personne n'a annulé les arriérés pour augmenter la capacité. C'est-à-dire s'il y a deux BS dans la zone de couverture d'un module radio, l'un répondra toujours et le second pourra entendre un autre paquet. Cependant, l'éther n'est pas du caoutchouc. Si chaque module radio prend une minute pour échanger des paquets, alors en une heure nous ne pouvons pas suspendre plus de 60 terminaux par BS, cela est soumis à l'absence de collisions. Très peu, surtout si vous vous souvenez que le rayon d'action de chaque BS dans la ville est d'environ 2 km, voire plus.

Alors non?

Il s'avère que notre réseau LoRaWAN est limité uniquement aux appareils avec une sortie impulsionnelle et des systèmes de surveillance, où est enregistré le voyage?

Non.

Nous avons juste essayé d'utiliser le concept de l'Internet des personnes là où cela ne peut pas être fait. D'accord, c'est une habitude pour nous d'utiliser excessivement un canal Internet stable. Par exemple, ouvrez une vidéo, saisissez du stock dans le tampon et ne regardez pas. C'est-à-dire le trafic passera, mais ne sera en fait pas utilisé.

Cependant, tout est différent ici. Nous avons peu de vitesse, pas de temps d'antenne non plus. Il doit être utilisé avec parcimonie. À quoi pouvez-vous penser?

La réponse est en surface. Ne conduisez pas un tas de trafic aérien de protocole sur RS-485 via LoRa.

Le script d'interrogation peut être téléchargé sur le module radio lui-même. Il interrogera le compteur sur place avec une certaine fréquence et ne nous enverra que des valeurs sèches et pré-convenues.

Cette méthode a deux inconvénients:

• Un tel module radio nécessite certaines ressources informatiques. Ce n'est pas un gros problème au niveau actuel de développement technologique.
• Un tel module radio consomme plus d'énergie. Mais dans le cas d'un canal transparent, nous sommes obligés d'utiliser la classe C, qui ne vit pas non plus sur piles. C’est ça.

Mais nous obtenons toutes les informations dont nous avons besoin dans 2-3 packages. Et puis tout ira dans un seul, si vous avez besoin de plusieurs paramètres. En effet, il arrive souvent que nous n'ayons pas besoin de passer TOUS, un ensemble de valeurs assez limité.

Le module radio peut transmettre des données, disons, une fois par heure. Et côté serveur, nous les mettrons en stockage. Si vous devez accéder à l'archive, le serveur n'a même pas besoin d'interroger l'appareil.

Bien sûr, vous devez avoir une sorte de module radio universel dans lequel divers scripts sont chargés. Et une interface capable de percevoir de telles informations. Ce n'est pas un moyen facile, mais seulement il répond à toutes les exigences et limitations.

Pour le moment, de plus en plus de fabricants prennent cette décision. Vega prépare des appareils similaires; icbcom, ORION M2M et d'autres l'ont déjà.

Parce que Si nous utilisons une interface auto-écrite, nous avons des développements similaires. À un moment donné, il est devenu clair que si nous n'allions pas plus loin, nous ne pourrions tout simplement pas travailler.

En plus des astuces pour économiser du trafic, nous avons toujours besoin d'un bon réseau dans lequel les appareils fonctionnent à une fréquence minimale et à une vitesse maximale. Je souligne - pas un tel réseau dans lequel tous les appareils avec SF = 7. Vous n'y arriverez toujours pas.

Un tel réseau qui cherche SF = 7. Cela signifie une planification et un ADR compétents.

En sortie, nous obtenons des vitesses suffisantes pour que les paquets voyagent, toujours un grand nombre de modules radio par BS et la possibilité de travailler avec des interfaces d'un niveau supérieur à la sortie d'impulsion. Ce qui était nécessaire.

Chers collègues PS, je suis reconnaissant à tous pour vos commentaires. Dites-moi, êtes-vous toujours intéressé à en apprendre davantage sur LoRaWAN ou l'Internet des objets? Les réponses peuvent m'écrire en PM ou dans les commentaires. Pour les demandes les plus intéressantes ou massives, des articles seront publiés.