Notes IoT provider. Pitfalls survey of housing and communal services counters
Hello, dear lovers of the Internet of Things. In this article, I would again like to talk about utilities and survey metering.
From time to time, another major telecom player tells how soon he enters this market and blows everyone under him. Every time with such stories I think: “guys, good luck!”
You have no idea where to climb.
So that you 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.
')
If we are not talking about individual metering devices, but those that are in basements, boiler rooms and enterprises, most of them are now equipped with a telemetric output. Less pulsed, more often - RS-485/232 or Ethernet. As a rule, the most "bread" metering devices - those that consider heat. It is for their dispatching willing to pay in the first place.
I have already stopped 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. Packet description goes a higher level in the data transfer standard that runs 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 required. Even if Modbus, it may still be somewhat modified.
In fact, for each metering device you need your own survey script, which is able to “talk” with it and interview it. Hence, the dispatch system is a set of scripts for each individual counter. Database where all this is stored. And a certain 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.
How to write them? Well, obviously, buy a metering device, pick 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 differ. Sometimes slightly, sometimes significantly. Buying something, you get the latest generation. The subscriber, however, is more likely to have something more ancient. It is no longer sold in stores. And the subscriber will not change the metering station.
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 further modified it already on real devices. It’s impossible to do this in a laboratory, only during the work with live subscribers.
It took us a long time to create such a bundle. Now the algorithm is worked out. The initial patterns were constantly adjusted 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 "not so." When such a device appears, it is connected in a standard pattern and the survey script is modified along the way. At the time of integration subscriber works for free. He is notified that he is still living in test mode. The integration process itself is a rather unpredictable thing. It happens that you need to make a minimum of corrections. There is a difficult process with the departure to the object, shoveling literature and consistent overcoming the rake.
The task is not easy, but solvable. The result is a working script. The larger the library of scripts, the easier it is to live.
The second problem.
To make you aware of the complexity of this work, I will give an example. Take the extremely popular heat meter VKT-7.
In itself, the name still does not tell us anything. CGT-7 has several iron solutions. What is the interface inside it?
There are different options. There can be output in a standard DB-9 block (this is RS-232). Maybe just a terminal block with RS-485 pins. Maybe even a network card with RJ-45 (in this case, ModBus is packaged in Ethernet).
Or maybe nothing at all. Just a bare metering device. You can install an interface output into it, it is sold by the manufacturer separately and costs money. The main problem - to install it, you need to open the counter 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 resource representative, performs the necessary modifications, after which the metering device is again sealed.
Depending on the installed interface, further refinement is performed. For example, we decided to connect the metering device by wire. This is the simplest option, if there is our switch in 100-m availability, then it is redundant to be wise with LoRa. Simply cable to our network, to an isolated VLAN.
For RS-485/232 you need a converter to Ethernet. Many will immediately remember MOX, but it is expensive. For our solutions, we have selected a Chinese solution cheaper.
If the output is immediately Ethernet, then the converter is not needed.
Question. Suppose we set the interface output ourselves. Can make your life easier and immediately put Ethernet everywhere?
It is not always possible. We must look at the execution of the case. It may not have the necessary hole for the interface to rise as it should. And the counter, remember, is in our basement. Or in the boiler room. There high humidity, tightness can not be broken. Finishing the body with a file is a bad idea. It is better to put something that does not initially require large alterations. Often - RS-485 is the only way out.
Farther. Is the meter connected to a guaranteed power supply? If not, he lives on battery. In this mode, it is designed for manual survey once a month for three minutes. Constant appeal to VKT-7 will drop his battery. So, you need to pull the guaranteed power and put the voltage converter.
The power module is different for each meter manufacturer. This may be an external block on a DIN rail or an integrated converter.
It turns out that in our warehouse should always be stored a set of different interfaces and power modules for each counter. The nomenclature is impressive there.
Of course, all this as a result will be paid by the subscriber. But he will not wait a month until the desired device comes. And he needs an estimate to connect here and now. So technological reserve falls on our shoulders.
All that I have described turns into a clear technical connection card so that field engineers do not think that they met the beast in the next basement and what they need for its work.
The technical map is adjacent to the general connection regulations. After all, it’s not enough to include the counter in our network, we still need to throw the same VLAN on the switch port, we need to diagnose it and make a test survey. We strive to automate the entire process as much as possible in order to avoid mistakes and not to attract the extra power of engineers.
Well, they wrote technical cards, regulations, automation. Established logistics.
Data is read and sent to the database.
The subscriber from these numbers is not hot nor cold. He needs a report. Desirable in the form in which he was accustomed. It is even better, if at once in the form of a report that is understandable to him, which he can print, sign and hand over. So, we need a simple and clear interface that shows information on the metering device and can automatically generate a report.
Here our zoo continues. The fact is that there are several report forms. At their core, they reflect the same (consumed heat), but in different ways.
Some of the subscribers report in absolute values ​​(that is, values ​​are written in the graph of heat consumption, starting with the installation of the meter), someone in the deltas (this is when we write consumption over a period of time without reference to initial values). In fact, they use not common standards, but established practice. There have been cases when subscribers see all the values ​​that they need (the amount of heat consumed, the amount of coolant supplied and gone, the temperature difference), but the columns in the report are not in the sequence.
Hence the next step - the report should be customizable. That is, the subscriber himself chooses what sequence he goes in and what resources are in his document.
There is an interesting point. Everything is good if our metering device is installed correctly. But it happens that the installer, when installing the ITP, got stuck and incorrectly set the time for the metering device. We met the devices that think - in the yard in 2010. In our system, it will look like zero readings for the current date, and real consumption - if you choose 2010. Here are very help out the delta. That is, we say that so many things have happened over the past 24 hours.
It would seem, why such difficulties? So hard to let the clock down?
Exactly with VKT-7, this will lead to the complete reset of the counter and the removal of archives from it.
The subscriber will have to prove to resource workers that he put the ITP not yesterday, and already about five years.
And finally, the cherry on the cake.
We have a metering device, there is a report. Between them is our system, which this report forms. Do you believe her?
I am yes. But how to prove that nothing changes inside us, that we do not distort the values. This is a question of certification. The survey system must have a certificate that confirms its impartiality. All large systems, such as LERS, I Energetik and other similar certificates have. We got it, too, although it is expensive and time consuming.
Of course, you can always cut the corner and buy something ready. But the developer will have to pay for this. And the developer can ask not only the entrance fee, but also the monthly fee. That is, we will be forced to share with him part of our pie.
The main problem is not that. Developing your own system is also very expensive and much harder. However, it gives an important advantage. We clearly understand how it works. We easily scale it, we can modify it, if such a need suddenly appeared. The subscriber receives a more complete service, and from our side one hundred percent control over the process.
That is why we have chosen the second path. In it, we have invested a year of life of our developers and field engineers. But now we clearly understand the work of the whole chain.
Looking back, I understand that without the knowledge gained, I simply could not correctly interpret the abnormal behavior of one or another counter.
In addition, on the basis of the distribution system you can build something more. Alarms on consumption exceedances, accident report. We are soon preparing to release a mobile application.
We went even further and into our platform (otherwise you wouldn’t call it) added the ability to receive appeals from residents, the ability to manage our “smart intercoms”, right there control of street lighting and a few more projects I haven’t written about yet.
All this is difficult, brainstroke and long. But the result is worth it. Subscribers get a finished, comprehensive product.
Each operator who plans to go to housing and communal services will definitely take this path. Will it pass?
There is a question. It's not even about money. As I wrote above, there is a need for a bunch of work in the field and development. Not all big players are used to this. If your developers are sitting in Moscow, and connections are made in Novosibirsk, then your time on the finished product is significantly stretched.
Time will tell who will hold on in this market, and who will say - yes, well, go to hell! But one thing I know clearly - to come and take market share solely with money will not work. This process requires unconventional approaches, good engineers, digging in the regulatory framework, communicating with resource workers and subscribers, and constantly identifying and overcoming the rake.
PS In this article, I consciously focused on the heat and did not mention electricity or water. I also describe the cable connection. If we have a pulse output - there are some nuances, like mandatory checks after installation. It may be that the wire does not reach, then in the course goes LoRaWAN. It is simply unrealistic to describe our entire platform and the stages of its development in one article.
From time to time, another major telecom player tells how soon he enters this market and blows everyone under him. Every time with such stories I think: “guys, good luck!”
You have no idea where to climb.
So that you 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, most of them are now equipped with a telemetric output. Less pulsed, more often - RS-485/232 or Ethernet. As a rule, the most "bread" metering devices - those that consider heat. It is for their dispatching willing to pay in the first place.
I have already stopped 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. Packet description goes a higher level in the data transfer standard that runs 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 required. Even if Modbus, it may still be somewhat modified.
In fact, for each metering device you need your own survey script, which is able to “talk” with it and interview it. Hence, the dispatch system is a set of scripts for each individual counter. Database where all this is stored. And a certain 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 metering device, pick 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 differ. Sometimes slightly, sometimes significantly. Buying something, you get the latest generation. The subscriber, however, is more likely to have something more ancient. It is no longer sold in stores. And the subscriber will not change the metering station.
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 further modified it already on real devices. It’s impossible to do this in a laboratory, only during the work with live subscribers.
It took us a long time to create such a bundle. Now the algorithm is worked out. The initial patterns were constantly adjusted 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 "not so." When such a device appears, it is connected in a standard pattern and the survey script is modified along the way. At the time of integration subscriber works for free. He is notified that he is still living in test mode. The integration process itself is a rather unpredictable thing. It happens that you need to make a minimum of corrections. There is a difficult process with the departure to the object, shoveling literature and consistent overcoming the rake.
The task is not easy, but solvable. The result is a working script. The larger the library of scripts, the easier it is to live.
The second problem.
Technological connection cards
To make you aware of the complexity of this work, I will give an example. Take the extremely popular heat meter VKT-7.
In itself, the name still does not tell us anything. CGT-7 has several iron solutions. What is the interface inside it?
There are different options. There can be output in a standard DB-9 block (this is RS-232). Maybe just a terminal block with RS-485 pins. Maybe even a network card with RJ-45 (in this case, ModBus is packaged in Ethernet).
Or maybe nothing at all. Just a bare metering device. You can install an interface output into it, it is sold by the manufacturer separately and costs money. The main problem - to install it, you need to open the counter 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 resource representative, performs the necessary modifications, after which the metering device is again sealed.
Depending on the installed interface, further refinement is performed. For example, we decided to connect the metering device by wire. This is the simplest option, if there is our switch in 100-m availability, then it is redundant to be wise with LoRa. Simply cable to our network, to an isolated VLAN.
For RS-485/232 you need a converter to Ethernet. Many will immediately remember MOX, but it is expensive. For our solutions, we have selected a Chinese solution cheaper.
If the output is immediately Ethernet, then the converter is not needed.
Question. Suppose we set the interface output ourselves. Can make your life easier and immediately put Ethernet everywhere?
It is not always possible. We must look at the execution of the case. It may not have the necessary hole for the interface to rise as it should. And the counter, remember, is in our basement. Or in the boiler room. There high humidity, tightness can not be broken. Finishing the body with a file is a bad idea. It is better to put something that does not initially require large alterations. Often - RS-485 is the only way out.
Farther. Is the meter connected to a guaranteed power supply? If not, he lives on battery. In this mode, it is designed for manual survey once a month for three minutes. Constant appeal to VKT-7 will drop his battery. So, you need to pull the guaranteed power and put the voltage converter.
The power module is different for each meter manufacturer. This may be an external block on a DIN rail or an integrated converter.
It turns out that in our warehouse should always be stored a set of different interfaces and power modules for each counter. The nomenclature is impressive there.
Of course, all this as a result will be paid by the subscriber. But he will not wait a month until the desired device comes. And he needs an estimate to connect here and now. So technological reserve falls on our shoulders.
All that I have described turns into a clear technical connection card so that field engineers do not think that they met the beast in the next basement and what they need for its work.
The technical map is adjacent to the general connection regulations. After all, it’s not enough to include the counter in our network, we still need to throw the same VLAN on the switch port, we need to diagnose it and make a test survey. We strive to automate the entire process as much as possible in order to avoid mistakes and not to attract the extra power of engineers.
Well, they wrote technical cards, regulations, automation. Established logistics.
Where else did the pitfalls lurk?
Data is read and sent to the database.
The subscriber from these numbers is not hot nor cold. He needs a report. Desirable in the form in which he was accustomed. It is even better, if at once in the form of a report that is understandable to him, which he can print, sign and hand over. So, we need a simple and clear interface that shows information on the metering device and can automatically generate a report.
Here our zoo continues. The fact is that there are several report forms. At their core, they reflect the same (consumed heat), but in different ways.
Some of the subscribers report in absolute values ​​(that is, values ​​are written in the graph of heat consumption, starting with the installation of the meter), someone in the deltas (this is when we write consumption over a period of time without reference to initial values). In fact, they use not common standards, but established practice. There have been cases when subscribers see all the values ​​that they need (the amount of heat consumed, the amount of coolant supplied and gone, the temperature difference), but the columns in the report are not in the sequence.
Hence the next step - the report should be customizable. That is, the subscriber himself chooses what sequence he goes in and what resources are in his document.
There is an interesting point. Everything is good if our metering device is installed correctly. But it happens that the installer, when installing the ITP, got stuck and incorrectly set the time for the metering device. We met the devices that think - in the yard in 2010. In our system, it will look like zero readings for the current date, and real consumption - if you choose 2010. Here are very help out the delta. That is, we say that so many things have happened over the past 24 hours.
It would seem, why such difficulties? So hard to let the clock down?
Exactly with VKT-7, this will lead to the complete reset of the counter and the removal of archives from it.
The subscriber will have to prove to resource workers that he put the ITP not yesterday, and already about five years.
And finally, the cherry on the cake.
Certification
We have a metering device, there is a report. Between them is our system, which this report forms. Do you believe her?
I am yes. But how to prove that nothing changes inside us, that we do not distort the values. This is a question of certification. The survey system must have a certificate that confirms its impartiality. All large systems, such as LERS, I Energetik and other similar certificates have. We got it, too, although it is expensive and time consuming.
Of course, you can always cut the corner and buy something ready. But the developer will have to pay for this. And the developer can ask not only the entrance fee, but also the monthly fee. That is, we will be forced to share with him part of our pie.
Why is it all?
The main problem is not that. Developing your own system is also very expensive and much harder. However, it gives an important advantage. We clearly understand how it works. We easily scale it, we can modify it, if such a need suddenly appeared. The subscriber receives a more complete service, and from our side one hundred percent control over the process.
That is why we have chosen the second path. In it, we have invested a year of life of our developers and field engineers. But now we clearly understand the work of the whole chain.
Looking back, I understand that without the knowledge gained, I simply could not correctly interpret the abnormal behavior of one or another counter.
In addition, on the basis of the distribution system you can build something more. Alarms on consumption exceedances, accident report. We are soon preparing to release a mobile application.
We went even further and into our platform (otherwise you wouldn’t call it) added the ability to receive appeals from residents, the ability to manage our “smart intercoms”, right there control of street lighting and a few more projects I haven’t written about yet.
All this is difficult, brainstroke and long. But the result is worth it. Subscribers get a finished, comprehensive product.
Each operator who plans to go to housing and communal services will definitely take this path. Will it pass?
There is a question. It's not even about money. As I wrote above, there is a need for a bunch of work in the field and development. Not all big players are used to this. If your developers are sitting in Moscow, and connections are made in Novosibirsk, then your time on the finished product is significantly stretched.
Time will tell who will hold on in this market, and who will say - yes, well, go to hell! But one thing I know clearly - to come and take market share solely with money will not work. This process requires unconventional approaches, good engineers, digging in the regulatory framework, communicating with resource workers and subscribers, and constantly identifying and overcoming the rake.
PS In this article, I consciously focused on the heat and did not mention electricity or water. I also describe the cable connection. If we have a pulse output - there are some nuances, like mandatory checks after installation. It may be that the wire does not reach, then in the course goes LoRaWAN. It is simply unrealistic to describe our entire platform and the stages of its development in one article.
Source: https://habr.com/ru/post/449668/
All Articles