Hello, dear Internet of Things enthusiasts. In this article, I would like to talk again about housing and utility services and the surveying of metering devices.
Periodically, another major telecom player announces how soon they will enter this market and sweep everyone under their control. Each time such announcements are made, I think: 'Good luck, guys!'
You can't even imagine what you're getting into.
To give you an idea of the scale of the problem, I’ll briefly share a portion of our experience in developing the 'Smart City' platform, specifically the part that is responsible for dispatching.
The overall idea and initial challenges
When talking not about individual metering devices, but those located in basements, boiler rooms, and enterprises, most of them are now equipped with telemetry outputs. Less frequently with impulse output, and more often with RS-485/232 or Ethernet. Typically, the most valuable metering devices are those that measure heat. It is precisely for their dispatching that payments are made first.
I have already detailed the features of RS-485 in my article. In brief, it is simply a data transmission interface. Essentially, it includes requirements for electrical impulses and communication lines. The packet descriptions occur at a higher level, in the data transmission standards that operate over RS-485. What those standards are depends on the manufacturer. Often Modbus, but not necessarily. Even if it is Modbus, it can still turn out to be somewhat modified.
In essence, each metering device requires its own polling script that can 'communicate' with it and query it. This means that the dispatching system is a set of scripts tailored for each individual meter, a database to store all this information, and some user interface that allows the user to generate the reports they need.
It may seem straightforward. The devil, as always, is in the details.
Let's start with the first part.
Scripts
How to write them? Well, obviously, you need to buy a metering device, take it apart, learn how to communicate with it, and integrate it into the overall platform.
Unfortunately, this solution will only cover part of our needs. Typically, a popular counter has several generations, and the script for each generation can differ. Sometimes slightly, sometimes significantly. When purchasing something, you acquire the latest generation. However, a subscriber is highly likely to have something much older that is no longer sold in stores. And the subscriber will not change their metering unit.
This leads us to the first problem. Writing such scripts requires a solid connection between software developers and engineers in the field. We purchased the latest generation, created an initial template, and then modified it on real devices. Doing this in a lab is unrealistic; it can only be done while working with live subscribers.
We spent considerable time establishing this connection. The algorithm is now fine-tuned. The initial templates were continuously adjusted and supplemented based on what we encountered in our practice. Naturally, subscribers were informed if their specific counter turned out to be slightly different. When such a device appears, it connects according to the standard scheme, and the polling script is modified on the go. During the integration period, the subscriber works for free. They are notified that they are temporarily in test mode. The integration process itself is quite unpredictable. Sometimes minimal corrections are needed. Other times, it’s a complex process requiring site visits, extensive literature reviews, and sequentially overcoming obstacles.
The task is not easy, but it is achievable. The end result is a functional script. The larger the library of scripts, the easier it is to manage.
The second problem.
Connection technology cards
To understand the complexity of this work, let me provide an example. Let's take the very popular heat meter VKT-7.
The name alone doesn't tell us much. The VKT-7 has several hardware solutions. What kind of interface does it have internally?
There are different options. It could have a standard DB-9 connector (this is RS-232). It might just have a terminal block with RS-485 contacts. It could even have a network card with RJ-45 (in this case, ModBus is packaged within Ethernet).
Or maybe nothing at all. Just a bare meter. You can install an interface output into it, which is sold separately by the manufacturer for a fee. The main issue is that installing it requires opening the meter and breaking the seals. This means that the utility company must be involved in this process. They are notified that the seals will be broken, a date is set, and our engineer makes the necessary modifications in the presence of a representative from the utility company, after which the meter is resealed.
Depending on the installed interface, further modifications are made. For example, if we decided to connect the meter via cable. This is the simplest option; if there is our switch within 100 meters, then using LoRa is excessive. It's easier to use a cable in our network, in an isolated VLAN.
For RS-485/232, a converter to Ethernet is needed. Many will immediately think of MOXA, but that's expensive. For our solutions, we have chosen a more affordable Chinese option.
If the output is Ethernet right away, then no converter is needed.
Question. Suppose we install the interface output ourselves. Can we make our lives easier by installing Ethernet everywhere?
Not always is this possible. You need to look at the housing design. It may not have the necessary hole for the interface to fit properly. And the meter, I remind you, is located in our basement or in the boiler room. There is high humidity, and we cannot compromise on airtightness. Modifying the housing with a file is a bad idea. It is better to install something that doesn’t require extensive modifications from the start. Often, RS-485 is the only option.
Next. Is the meter connected to a guaranteed power supply? If not, then it runs on batteries. In this mode, it is designed for manual polling once a month for three minutes. Constantly querying the VKT-7 will drain its battery. Therefore, guaranteed power supply needs to be arranged, and a voltage converter installed.
For each meter manufacturer, the power module is different. It may be an external block on a DIN rail or a built-in converter.
This means that our warehouse must always store a set of various interfaces and power modules for each meter. The range of these is quite impressive.
Of course, in the end, the subscriber will pay for all of this. But they won't wait a month for the necessary device to arrive. They need a connection estimate here and now. So, the technological burden falls on our shoulders.
Everything I've described is wrapped up in a clear technical connection map, so that local engineers aren't left wondering what kind of beast they're dealing with in another basement and what they need for it to work.
The technical map coexists with the overall connection regulations. After all, it's not enough to just connect the meter to our network; we also need to add that VLAN to the switch port, conduct diagnostics, and perform a test survey. We strive to automate the entire process as much as possible to avoid errors and not burden the engineers unnecessarily.
Well, we've written the technical maps, regulations, and automation plans. We've organized logistics.
Where else might there be hidden pitfalls?
The data is read and poured into the database.
The subscriber is indifferent to these numbers. They need a report. Ideally, in the format they're accustomed to. Even better if it's immediately in a clear report that they can print, sign, and submit. This means a simple and intuitive interface is needed, one that displays information about the measuring device and can automatically generate a report.
Here our zoo continues. The thing is, there are several report formats. Essentially, they reflect the same thing (consumed heat) but in different ways.
Some subscribers report in absolute values (meaning the heat consumption column shows values starting from the installation of the meter), while others report in deltas (when consumption for a period is stated without reference to the initial values). Essentially, there are no uniform standards, just established practices. There have been cases where subscribers see all the values they need (the amount of consumed heat, the volume of supplied and drained heating medium, temperature differences), but the columns in the report are not in the right order.
Hence the next step — the report must be customizable. This means the subscriber chooses the order in which data appears and which resources are included in their document.
Here's an interesting point. Everything is fine if our measuring device is installed correctly. However, there are times when the installation company makes mistakes during the setup of the heating substation and incorrectly sets the time on the meter. We have encountered devices that think it's the year 2010. In our system, this would result in zero readings for the current date, while actual consumption would reflect data from 2010. This is where deltas come in handy. So we say that during the past 24 hours, a certain amount has accumulated.
It may seem like why complicate things? Is it really that hard to set the clock?
Exactly with the VKT-7 this will lead to a complete reset of the meter and the deletion of its archives.
The subscriber will have to prove to the utility companies that they installed the heating substation not just yesterday, but five years ago.
And finally, the cherry on the cake.
Certification
We have a measuring device, and we have a report. Between them is our system, which generates this report. Do you trust it?
I do. But how do we prove that nothing is altered inside, that we don't distort the values? This is already a question of certification. The polling system must have a certificate that confirms its impartiality. All major systems, such as LERS, I Energy, and others, have a similar certificate. We also obtained one, although it was expensive and time-consuming.
Of course, one can always cut corners and buy something pre-made. But you will have to pay the developer for that. And the developer might ask for not only an initial fee but also a subscription fee. It means we would have to share part of our pie with them.
What's all this for?
The main problem isn't that. Developing our own system is also very expensive and significantly more complicated. However, it provides an important advantage. We clearly understand how it works. We can easily scale it, and we can modify it if the need arises. The subscriber receives a more complete service, and from our side, we maintain 100% control over the process.
That's precisely why we chose the second path. We invested a year of our developers' and field engineers' lives into it. As a result, we now have a clear understanding of the entire chain's operation.
Looking back, I realize that without the knowledge gained, I simply couldn't have correctly interpreted the abnormal behavior of any given meter.
Additionally, based on the dispatching system, something greater can be built. Alarms for consumption exceeding limits, incident reports. We're soon launching a mobile application.
We took it a step further and added the ability to receive requests from residents to our platform (it wouldn’t be right to call it anything else), along with control over our 'smart intercoms,' monitoring outdoor lighting, and several other projects I haven’t mentioned yet.
All this is complex, brain-bending, and time-consuming. But the results are worth it. Subscribers receive a comprehensive product ready for use.
Every operator planning to enter the public utilities sector will inevitably take this path. Will they succeed?
Here lies the question. It's not even about the money. As I mentioned earlier, a combination of fieldwork and development is essential. Not all major players are accustomed to this. If your developers are based in Moscow while the connections are being made in Novosibirsk, your time to market will significantly extend.
Time will tell who will remain in this market and who will say, 'I’ll pass!' But one thing I know for sure — coming in and capturing market share solely with money won’t work. This process requires unconventional approaches, skilled engineers, digging into regulations, engaging with resource providers and subscribers, and constantly identifying and overcoming obstacles.
P. S. In this article, I've consciously focused on heating and not mentioned electricity or water. I also describe connections via cable. If we have a pulse output, there are specifics, such as mandatory checks after installation. There may be cases where a wire cannot reach, then LoRaWAN is used. It’s simply unrealistic to describe our entire platform and its development stages in one article.
Source: habr.com
