Bonjour, chers amateurs de l'Internet des Objets. Dans cet article, j'aimerais à nouveau parler de la gestion d'immeuble et de l'interrogation des appareils de comptage.
Périodiquement, un autre grand acteur du secteur des télécommunications annonce son intention d'entrer sur ce marché et de tout dominer. Chaque fois que j'entends de telles histoires, je pense : « Bonne chance, les gars ! »
Vous n'avez même pas idée de ce dans quoi vous vous engagez.
Pour que vous compreniez l'ampleur du problème, je vais brièvement partager une partie de notre expérience dans le développement de la plateforme « Ville Intelligente ». Celle qui concerne la dispatching.
L'idée générale et les premières difficultés
Si l'on ne parle pas des appareils de comptage individuels, mais de ceux qui se trouvent dans les sous-sols, les chaufferies et les entreprises, la plupart d'entre eux sont actuellement équipés d'une sortie télémétrique. Plus rarement d'un émetteur d'impulsions, plus souvent — RS-485/232 ou Ethernet. En général, les appareils de comptage les plus « rentables » sont ceux qui mesurent la chaleur. C'est pour leur dispatching que l'on est prêt à payer en premier lieu.
J'ai déjà longuement abordé dans mon article les spécificités de RS-485. Pour résumer — c'est simplement une interface de transmission de données. En essence — des exigences concernant les impulsions électriques et la ligne de communication. La description des paquets se fait à un niveau supérieur, dans la norme de transmission de données qui fonctionne au-dessus de RS-485. Quant à la norme qui sera utilisée, cela dépend du fabricant. Souvent Modbus, mais ce n'est pas toujours le cas. Même s'il s'agit de Modbus, il peut encore être quelque peu modifié.
En fait, chaque appareil de comptage nécessite son propre script d'interrogation capable de « communiquer » avec lui et de l'interroger. Par conséquent, le système de dispatching est un ensemble de scripts pour chaque compteur individuel. Une base de données où tout cela est stocké. Et une interface utilisateur à partir de laquelle il peut générer le rapport dont il a besoin.
Cela ne semble pas compliqué. Le diable, comme toujours, est dans les détails.
Commençons par la première partie.
Scripts
Comment les écrire ? Eh bien, il est évident qu'il faut acheter un appareil de comptage, l'ouvrir, apprendre à communiquer avec lui et l'intégrer dans la plateforme globale.
Malheureusement, cette solution ne couvrira qu'une partie de nos besoins. En général, un compteur populaire a plusieurs générations, et le script pour chaque génération peut varier. Parfois un peu, parfois beaucoup. En achetant quelque chose, vous obtenez la dernière génération. Tandis qu'un abonné aura très probablement quelque chose de plus ancien. Cela n'est déjà plus en vente dans les magasins. Et il ne changera pas le module de comptage.
D'où la première problématique. Écrire de tels scripts est un lien étroit entre les développeurs de logiciels et les ingénieurs sur le terrain. Nous avons acheté la dernière génération, écrit un modèle initial, puis l'avons modifié sur de véritables appareils. Faire cela en laboratoire est irréaliste, cela ne peut se faire que dans le cadre du travail avec des abonnés réels.
Nous avons consacré beaucoup de temps à créer ce lien. Maintenant, l'algorithme est au point. Les modèles initiaux étaient constamment corrigés et complétés, en fonction de ce que nous rencontrions dans notre pratique. Bien sûr, les abonnés étaient informés si jamais leur compteur était légèrement "différent". Lorsqu'un tel appareil apparaît, il est connecté selon le schéma standard et le script de sondage est modifié en cours de route. Pendant l'intégration, l'abonné travaille gratuitement. Il est informé qu'il vit encore en mode test. Le processus d'intégration est assez imprévisible. Parfois, il faut apporter un minimum de corrections. Parfois, c'est un processus complexe avec des visites sur site, un examen approfondi de la documentation et le franchissement successif des obstacles.
La tâche n'est pas simple, mais elle est réalisable. Le résultat — un script fonctionnel. Plus la bibliothèque de scripts est grande, plus la vie est facile.
Deuxième problème.
Cartes technologiques de connexion
Pour que vous compreniez la complexité de ce travail, prenons l'exemple d'un compteur de chaleur très populaire, le VKT-7.
Le nom en soi ne nous dit encore rien. Le VKT-7 a plusieurs solutions matérielles. Quel est l'interface interne ?
Il existe différentes options. Cela peut être une sortie sur un connecteur standard DB-9 (c'est RS-232). Cela peut simplement être une borne à vis avec des contacts RS-485. Cela peut même être une carte réseau avec RJ-45 (dans ce cas, ModBus est encapsulé dans Ethernet).
Ou peut-être rien du tout. Juste un appareil de mesure nu. Il est possible d'y installer une sortie d'interface, qui est vendue séparément par le fabricant et coûte de l'argent. Le principal problème est que pour son installation, il est nécessaire d'ouvrir le compteur et de briser les plombs. Cela implique l'organisation de fourniture de ressources. Elle est informée que les plombs seront brisés, un jour est fixé et notre ingénieur, en présence d'un représentant de l'organisation, effectue les modifications nécessaires, après quoi l'appareil de mesure est à nouveau plombé.
En fonction de l'interface installée, des modifications supplémentaires sont effectuées. Par exemple, nous avons décidé de connecter l'appareil de mesure par câble. C'est la solution la plus simple, si notre commutateur est à 100 mètres de distance, alors utiliser LoRa serait excessif. Il est plus simple d'utiliser un câble dans notre réseau, dans un VLAN isolé.
Pour RS-485/232, un convertisseur vers Ethernet est nécessaire. Beaucoup penseront immédiatement à MOXA, mais c'est cher. Pour nos solutions, nous avons trouvé une alternative chinoise moins chère.
Si la sortie est immédiatement Ethernet, alors aucun convertisseur n'est nécessaire.
Question. Supposons que nous installons nous-mêmes la sortie d'interface. Peut-on se faciliter la vie et installer directement de l'Ethernet partout ?
Ce n'est pas toujours possible. Il faut vérifier la conception du boîtier. Il se peut qu'il n'y ait pas de trou adéquat pour que l'interface s'installe correctement. Rappelons que le compteur est situé dans notre sous-sol. Ou dans la chaufferie. Là, l'humidité est élevée, il ne faut pas compromettre l'étanchéité. Retoucher le boîtier avec une lime est une mauvaise idée. Il est préférable d'installer quelque chose qui ne nécessite pas de grandes modifications dès le départ. Souvent, RS-485 est la seule option.
Ensuite. Le compteur est-il connecté à une alimentation garantie ? S'il ne l'est pas, il fonctionne sur batterie. Dans ce mode, il est prévu pour un relevé manuel une fois par mois pendant trois minutes. Un accès constant au VKT-7 déchargera sa batterie. Cela signifie qu'il faut tirer une alimentation garantie et installer un convertisseur de tension.
Pour chaque fabricant de compteurs, le module d'alimentation est différent. Cela peut être un bloc externe sur rail DIN ou un convertisseur intégré.
Il en résulte que notre entrepôt doit toujours contenir un ensemble de différentes interfaces et modules d'alimentation pour chaque compteur. Le choix y est vaste.
Bien sûr, tout cela sera finalement payé par l'abonné. Mais il ne va pas attendre un mois que le bon appareil arrive. Il lui faut un devis pour la connexion ici et maintenant. Donc, la réserve technologique pèse sur nos épaules.
Tout ce que j'ai décrit se transforme en une carte technique claire de la connexion, afin que les ingénieurs sur le terrain ne se demandent pas quel type d'équipement ils rencontrent dans un sous-sol et ce dont ils ont besoin pour le faire fonctionner.
La carte technique coexiste avec le règlement général de connexion. Il ne suffit pas d'intégrer le compteur dans notre réseau, il faut également appliquer le VLAN sur le port du commutateur, effectuer un diagnostic et réaliser un sondage test. Nous cherchons à automatiser ce processus au maximum pour éviter les erreurs et ne pas mobiliser des ressources supplémentaires des ingénieurs.
C'est bon, nous avons rédigé des cartes techniques, un règlement et une automatisation. Nous avons mis en place la logistique.
Où d'autres pièges sont-ils cachés ?
Les données sont collectées et versées dans la base.
Pour l'abonné, ces chiffres ne lui apportent ni chaleur ni froid. Il a besoin d'un rapport. Idéalement, dans le format auquel il est habitué. Encore mieux, s'il peut avoir un rapport compréhensible, qu'il peut imprimer, signer et soumettre. Il nous faut donc une interface simple et claire qui affiche les informations de mesure et peut générer automatiquement un rapport.
Ici, notre zoo continue. Le fait est qu'il existe plusieurs formats de rapport. En essence, ils reflètent tous la même chose (chaleur consommée), mais par des voies différentes.
Certains abonnés rapportent des valeurs absolues (c'est-à-dire que dans la colonne de consommation de chaleur, les valeurs sont indiquées depuis l'installation du compteur), tandis que d'autres le font en deltas (cela signifie que nous écrivons la consommation sur une période sans relier cela aux valeurs de départ). En vérité, ils n'utilisent pas des normes uniques, mais une pratique établie. Il y a eu des cas où des abonnés voient toutes les valeurs dont ils ont besoin (quantité de chaleur consommée, volume de fluide caloporteur fourni et évacué, différence de température), mais les colonnes dans le rapport ne sont pas dans le bon ordre.
D'où la prochaine étape : le rapport doit être personnalisable. C'est-à-dire que l'abonné choisit lui-même l'ordre des éléments et quelles ressources sont présentes dans son document.
Il y a un point intéressant. Tout va bien si notre appareil de mesure est installé correctement. Mais parfois, l'organisation de montage, lors de l'installation de l'ITP, a fait des erreurs en définissant le temps pour l'appareil de mesure. Nous avons rencontré des dispositifs qui pensent que nous sommes en 2010. Dans notre système, cela apparaîtra comme des indications nulles à la date actuelle, alors que la consommation réelle sera celle de l'année 2010. Ici, les deltas sont très utiles. C'est-à-dire que nous disons qu'au cours des dernières 24 heures, il y a eu telle consommation.
On pourrait penser, pourquoi tant de complications ? Est-il si difficile de régler l'heure ?
C'est précisément avec le VK7 que cela entraînera une remise à zéro complète du compteur et la suppression des archives.
L'abonné sera contraint de prouver aux fournisseurs qu'il a installé l'ITP non pas hier, mais il y a déjà cinq ans.
Et enfin, la cerise sur le gâteau.
Certification
Nous avons un appareil de mesure, un rapport. Entre les deux, il y a notre système qui génère ce rapport. Y croyez-vous ?
Moi, oui. Mais comment prouver que rien ne change en interne, que nous ne falsifions pas les valeurs ? C'est déjà une question de certification. Le système d'interrogation doit absolument avoir un certificat qui confirme son impartialité. Tous les grands systèmes, comme LERS, Je suis Énergéticien et d'autres, possèdent un tel certificat. Nous l'avons obtenu aussi, bien que cela coûte cher et prenne beaucoup de temps.
Bien sûr, on peut toujours prendre un raccourci et acheter quelque chose de prêt. Mais cela nécessitera de payer au développeur. Et le développeur peut demander non seulement un frais d'entrée, mais aussi des frais d'abonnement. C'est-à-dire que nous serons contraints de partager une partie de notre gâteau avec lui.
À quoi bon tout cela ?
Le véritable problème n'est pas là. Développer son propre système est également très coûteux et beaucoup plus complexe. Cependant, cela offre un avantage important. Nous comprenons clairement comment cela fonctionne. Nous l'échelonnons facilement, nous pouvons le modifier si le besoin se présente. L'abonné reçoit un service plus complet, et de notre côté, un contrôle à cent pour cent sur le processus.
C'est exactement pour cela que nous avons choisi la deuxième voie. Nous y avons investi un an de vie de nos développeurs et de nos ingénieurs sur le terrain. Maintenant, nous comprenons clairement le fonctionnement de toute la chaîne.
En y regardant en arrière, je comprends que sans les connaissances acquises, je n'aurais tout simplement pas pu interpréter correctement le comportement anormal de tel ou tel compteur.
De plus, sur la base du système de dispatching, il est possible de construire quelque chose de plus grand. Des alarmes pour les dépassements de consommation, un rapport sur les pannes. Nous préparons bientôt le lancement d'une application mobile.
Nous sommes allés encore plus loin en intégrant dans notre plateforme (sinon, ce ne serait pas un nom approprié) la possibilité de recevoir des requêtes des résidents, la gestion de nos « interphones intelligents », le contrôle de l'éclairage public et encore plusieurs projets dont je n'ai pas encore parlé.
Tout cela est compliqué, casse-tête et long. Mais le résultat en vaut la peine. Les abonnés obtiennent un produit complet prêt à l'emploi.
Tout opérateur qui envisage d'entrer dans le secteur des services publics devra nécessairement emprunter ce chemin. Le franchira-t-il ?
C'est la question. Il ne s'agit même pas d'argent. Comme je l'ai mentionné précédemment, il est essentiel d'avoir un lien entre le travail sur le terrain et le développement. Tous les grands acteurs ne sont pas habitués à cela. Si vos développeurs sont assis à Moscou tandis que les connexions se font à Novossibirsk, le temps pour obtenir un produit final s'allonge considérablement.
Le temps montrera qui restera sur ce marché et qui décidera de le quitter. Mais une chose est claire pour moi : arriver et prendre une part de marché uniquement avec de l'argent ne fonctionnera pas. Ce processus nécessite des approches non conventionnelles, de bons ingénieurs, des efforts dans la réglementation, des échanges avec les ressources et les abonnés, ainsi qu'une identification et un surpassement constants des obstacles.
P. S. Dans cet article, je me suis délibérément concentré sur la chaleur et n'ai pas mentionné l'électricité ou l'eau. Je décris également la connexion par câble. Si nous avons une sortie impulsionnelle, il y a des nuances, comme les vérifications obligatoires après l'installation. Il se peut qu'il soit impossible d'atteindre avec un câble, alors LoRaWAN entre en jeu. Décrire toute notre plateforme et les étapes de son développement en un seul article est simplement irréaliste.
Source : habr.com
