Hello dear fans of the Internet of Things. In this article, I would like to talk again about housing and communal services and a survey of metering devices.
Periodically, another major telecom player tells how soon he will enter this market and crush everyone under him. Every time with such stories, I think: “guys, good luck!”
You don't even know where you're going.
For you to understand the scale of the problem, I will briefly describe a small part of our experience in developing the Smart City platform. That part of it that is responsible for dispatching.
General idea and first difficulties
If we are not talking about individual metering devices, but those that are in basements, boiler rooms and enterprises, then most of them are now equipped with a telemetry output. Less often pulsed, more often - RS-485/232 or Ethernet. As a rule, the most "bread" metering devices are those that consider heat. It is for their dispatching that they are ready to pay in the first place.
I have already dwelled in detail in my article on the features of RS-485. In short, it's just a data interface. In fact, the requirements for electrical impulses and communication lines. The description of the packets goes a level higher, in a data transfer standard that works on top of RS-485. And what will be there for the standard - it is at the mercy of the manufacturer. Often Modbus, but not necessarily. Even if Modbus, it can still be somewhat modified.
In fact, each metering device needs its own polling script, which can “talk” with it and interrogate it. This means that the dispatching system is a set of scripts for each individual counter. The database where all this is stored. And some user interface in which he can generate the report he needs.
Looks easy. The devil, as always, is in the details.
Let's start with the first part.
Scripts
How to write them? Well, obviously, buy a meter, open it up, learn how to communicate with it and integrate it into a common platform.
Unfortunately, this solution will cover only part of our needs. As a rule, a popular counter has several generations, and the script for each generation may be different. Sometimes a little, sometimes a lot. When you buy something, you get the latest generation. The subscriber, with a high degree of probability, will have something more ancient. It is no longer sold in stores. And the subscriber will not change the metering unit.
Hence the first problem. Writing such scripts is a tough bunch of software developers and engineers "on the ground". We bought the latest generation, wrote some initial template and then modified it on real devices. It is unrealistic to do this in the laboratory, only in the course of working with live subscribers.
It took us a lot of time to create such a bundle. Now the algorithm has been worked out. The initial templates were constantly corrected and supplemented, depending on what we met in our practice. Of course, the subscriber was warned if suddenly it was his counter that turned out to be a little bit “not like that”. When such a device appears, it is connected according to the standard scheme and the polling script is modified along the way. During the integration period, the subscriber works free of charge. He is notified that he is still living in test mode. The integration process itself is a rather unpredictable thing. Sometimes you need to make a minimum of corrections. There is a complex process with a visit to the object, shoveling literature and consistently overcoming the rake.
The task is not easy, but solvable. The result is a working script. The larger the script library, the easier it is to live.
The second problem.
Technological connection cards
To give you an idea of the complexity of this work, I will give an example. Let's take the extremely popular VKT-7 heat meter.
The name itself doesn't tell us anything. VKT-7 has several hardware solutions. What kind of interface does it have inside?
There are different options. There may be an output in a standard DB-9 block (this is RS-232). Maybe just a terminal block with RS-485 contacts. Maybe even a network card with RJ-45 (in this case, ModBus is packaged in Ethernet).
Or maybe nothing at all. Just a bare meter. You can install an interface output in it, it is sold by the manufacturer separately and costs money. The main trouble is that to install it, you need to open the meter and break the seals. That is, the resource-supplying organization is included in this process. She is notified that the seals will be broken, a day is appointed and our engineer, in the presence of a representative of the resource workers, performs the necessary improvements, after which the meter is sealed again.
Depending on the installed interface, further refinement is performed. For example, we decided to connect a meter by wire. This is the simplest option, if our switch is within 100 meters, then tricking with LoRa is redundant. It's easier with a cable to our network, to an isolated VLAN.
RS-485/232 requires a converter to Ethernet. Many will immediately remember MOHA, but it is expensive. For our solutions, we have chosen a cheaper Chinese solution.
If the output is immediately Ethernet, then the converter is not needed.
Question. Let's say we set the interface output ourselves. Can you make your life easier and immediately put Ethernet everywhere?
This is not always possible. We need to look at the execution of the body. He may not have the right hole for the interface to stand up as it should. And the counter, I remind you, is in our basement. Or in the boiler room. There is high humidity, the tightness cannot be violated. Finishing the case with a file is a bad idea. It is better to put something that initially does not require large alterations. Often - RS-485 is the only way out.
Further. Is the meter connected to a guaranteed power supply? If not, then it lives on batteries. In this mode, it is designed for manual polling once a month for three minutes. Constantly accessing the CGT-7 will drain its battery. So, you need to pull a guaranteed power supply and install a voltage converter.
For each manufacturer of meters, the power supply module is different. It can be an external unit on a DIN rail or a built-in converter.
It turns out that a set of various interfaces and power modules for each meter should always be stored in our warehouse. The range there is impressive.
Of course, all this will eventually be paid for by the subscriber. But he will not wait a month until the right device arrives. And he needs an estimate for connecting here and now. So the technological reserve falls on our shoulders.
Everything that I described turns into a clear technical connection card so that local engineers do not think what kind of animal they met in the next basement and what they need for it to work.
The technical map is adjacent to the general connection regulations. After all, it is not enough to include the meter in our network, you still need to throw the same VLAN on the switch port, you need to carry out diagnostics, make a test poll. We strive to automate the entire process as much as possible in order to avoid errors and not involve unnecessary forces of engineers.
Well, we wrote technical maps, regulations, automation. Set up logistics.
Where else are hidden pitfalls?
The data is read and poured into the database.
The subscriber from these figures is not hot or cold. He needs a report. Preferably in the form in which he is accustomed. Even better, if immediately in the form of a report that he can understand, which he can print, sign and submit. This means that you need a simple and understandable interface that shows information on the meter and can automatically generate a report.
Here our zoo continues. The fact is that there are several forms of the report. At their core, they reflect the same thing (heat consumed), but in different ways.
Some of the subscribers report in absolute values (that is, values are written in the heat consumption column starting from the installation of the meter), someone in deltas (this is when we write consumption for a period of time without reference to the initial values). In fact, they do not use uniform standards, but established practice. There have been cases when subscribers see all the values that they need (the amount of heat consumed, the volume of coolant supplied and gone, temperature difference), but the columns in the report are in the wrong sequence.
Hence the next step - the report must be customizable. That is, the subscriber himself chooses what goes in what sequence and what resources are in his document.
Here is an interesting point. Everything is fine if our meter is installed correctly. But it happens that the installation organization, when installing the ITP, messed up and incorrectly set the time for the meter. We've seen devices that think it's 2010. In our system, this will look like zero readings for the current date, and real consumption if we select 2010. This is where deltas come in handy. That is, we say that over the past day so much has been ticking.
It would seem, why such difficulties? Is it so hard to let the clock down?
It is precisely with VKT-7 that this will lead to a complete reset of the counter and the removal of archives from it.
The subscriber will be forced to prove to the resource managers that he installed the ITP not yesterday, but about five years ago.
And finally, the icing on the cake.
Certification
We have a meter, we have a report. Between them is our system that generates this report. Do you believe her?
I am yes. But how to prove that nothing changes inside us, that we do not distort the meaning. It's a matter of certification. The polling system must have a certificate that confirms its impartiality. All large systems, such as LERS, Ya Energetik and others, have a similar certificate. We also got it, although it is expensive and takes a lot of time.
Of course, you can always cut corners and buy something ready-made. But the developer will have to pay for this. And the developer can ask not only for an entrance fee, but also for a monthly fee. That is, we will be forced to share with him a part of our pie.
Why is it all?
The main problem is not this. Developing your own system is also very expensive and many times harder. However, it provides an important advantage. We clearly understand how it works. We easily scale it, we can modify it if such a need suddenly arises. The subscriber receives a more complete service, and from our side, one hundred percent control over the process.
That is why we chose the second path. We have invested a year of the life of our developers and field engineers in it. But now we clearly understand the work of the entire chain.
Looking back, I understand that without the knowledge gained, I simply could not correctly interpret the abnormal behavior of a particular counter.
In addition, something more can be built on the basis of the dispatching system. Consumption excess alarms, accident report. We have a mobile app coming soon.
We went even further and added to our platform (otherwise you can’t call it any other way) the ability to receive requests from residents, the ability to control our “smart intercoms”, immediately control street lighting and a few more projects that I haven’t written about yet.
All this is complex, brain-breaking and long. But the result is worth it. Subscribers receive a ready-made comprehensive product.
Each operator who plans to go into the housing and communal services will definitely take this path. Will it pass?
Here is a question. It's not even about the money. As I wrote above, what is needed here is a combination of work in the field and development. Not all major players are used to this. If your developers are in Moscow, and connections are made in Novosibirsk, then your time for the finished product is significantly stretched.
Time will tell who will hold out in this market, and who will say - well, he's gone to hell! But one thing I know for sure is that it will not work to come and take a market share solely with money. This process requires unconventional approaches, good engineers, digging into the regulation, communication with resource managers and subscribers, constant identification and overcoming of the rake.
PS In this article, I have deliberately focused on heat and do not mention electricity or water. I also describe the cable connection. If we have a pulse output, there are some nuances, such as mandatory reconciliations after installation. It may be that the wire cannot be reached, then LoRaWAN is used. It is simply unrealistic to describe our entire platform and the stages of its development in one article.
Source: habr.com