Hello, Habr! Our team monitors machines and installations throughout the country. In fact, we provide an opportunity for the manufacturer not to chase the engineer once again when “oh, it’s all broken,” but in fact it is necessary to press one button. Or when it broke not on the equipment, but nearby.
The basic problem is as follows. Here you are making an oil cracker, or a machine tool, or some other device for a plant. As a rule, the sale itself is extremely rare: it is usually a supply and service contract. That is, you guarantee that the piece of iron will work for 10 years without interruptions, and you are responsible for interruptions either financially, or provide strict SLA, or something like that.
In fact, this means that you need to regularly send an engineer to the site. As our practice shows, from 30 to 80% of trips are unnecessary. The first case - it would be possible to figure out what happened remotely. Or ask the operator to press a couple of buttons - and everything will work. The second case is “gray” schemes. This is when an engineer leaves, puts in the regulations a replacement or complex work, and he himself divides the compensation in half with someone from the factory. Or he simply enjoys the rest with his mistress (a real case) and therefore likes to travel more often. The plant doesn't mind.
The installation of monitoring requires the modification of hardware by a data transmission device, the transmission itself, some kind of data lake for their accumulation, parsing protocols and processing environment with the ability to see and compare everything. Well, with all this there are nuances.
Why is it impossible to do without remote monitoring?
It is corny expensive. A business trip for one engineer - at least 50 thousand rubles (plane, hotel, accommodation, daily allowance). Plus, it does not always work out to be torn, and the same person may be needed in different cities.
- In Russia, the supplier and the consumer are almost always quite far from each other. When you sold a product to Siberia, you do not know anything about it except what the supplier tells you. Neither how it works, nor under any conditions it is operated, nor, in fact, who pressed what button with crooked hands - you objectively do not have this information, you can only know it from the words of the consumer. This makes maintenance very difficult.
- . , , , , , , , , . « », . , , — , , , — .
- , , , , , . , , .
- - , , , , - , , , . , , , , - . — . , - . , . : « ». , , . .
- «» — . . : «, , : , , , - . , ». , - - , , , , . , , .
, ? ?
The problem is that if the suppliers more or less understand that the log needs to be constantly written somewhere (or understood over the past few decades), then the culture did not go further. The log is often needed to analyze cases with expensive repairs - whether it was an operator error or a real equipment breakdown.
To pick up a log, you often need to physically approach the equipment, open some kind of casing, expose the service connector, connect a cable to it and pick up the data files. Then stubbornly bang them for several hours to get a picture of the situation. Alas, this happens almost everywhere (well, either I have a one-sided point of view, since we work just with those industries where monitoring is just getting started).
Our main customers are equipment manufacturers. As a rule, they begin to think about the fact that it is worth doing some kind of monitoring, either after a major incident, or simply by looking at the travel bills for the year. But more often than not, we are talking about a major failure with the loss of money or reputation. Progressive leaders who think about "whatever happens" are rare. The fact is that usually the manager gets the old "fleet" of service contracts, and he doesn't see any point in installing sensors on new hardware, because it will only be needed in a couple of years.
In general, at some point the roasted rooster bites, and the time for modifications comes.
The data transfer itself is not very scary. The equipment usually already has sensors (or they are installed rather quickly), plus logs are already written and service events are noted. You just need to start sending all this. A common practice is that a modem, for example, with an embed-SIM, is inserted directly into the device from an X-ray machine to an automatic seeder and sends telemetry via the cellular network. Places without cellular coverage are usually quite far away and have been rare in recent years.
And then the same question begins as before. Yes, there are logs now. But they need to be put somewhere and somehow read. In general, you need some kind of visualization and analysis system for incidents.
And then we appear on the stage. More precisely, we often appear earlier, because the leaders of suppliers watch how their colleagues have done, and immediately go to us for advice on the selection of hardware for sending telemetry.
Market niche
In the West, the way to solve this situation comes down to three options: the Siemens ecosystem (very expensive, needed for very large units, as a rule, such as turbines), self-written mandulas or someone from local integrators helps. As a result, by the time all this came to the Russian market, an environment was formed where there is Siemens with its pieces of the ecosystem, Amazon, Nokia and several local ecosystems like 1C developments.
We entered the market as a unifying link that allows you to collect any data from any device using any (okay, almost any more or less modern) protocols, process them together and show them to a person in any required form: for this we have cool SDKs for everyone development environments and a visual designer of user interfaces.
As a result, we can collect all the data from the manufacturer's device, enter it into a storage on the server and collect a dashboard with alerts there.
This is how it looks (here the customer also made a visualization of the enterprise, this is a few hours in the interface):
And there are graphs from the equipment:
Alerts look like this: at the machine level, if the force on the executive body is exceeded or a collision occurs, a set of parameters is configured, and the system will inform the department or repair services when leaving for them.
Well, the most difficult thing is to predict the failure of nodes by their condition for prevention. If you understand the resource of each of the nodes, then you can greatly reduce the costs of those contracts where there is payment for downtime.
Summary
This story would sound quite simple: well, we realized that we need to send data, monitoring and analysis, well, we chose a vendor and implemented it. Well, that's it, everyone is happy. If we are talking about self-written systems at their own factory, then, oddly enough, the systems quickly become unreliable. We are talking about the banal loss of logs, inaccurate data, failures in collection, storage and receipt. A year or two after installation, they begin to delete old logs, which also does not always end well. Although there is practice - 10 GB is collected from one machine per year. This is solved for five years by buying another hard drive for 10 thousand rubles ... At some point it turns out that it is not the transmission equipment itself that is primary, but the system that allows the data to be analyzed. The convenience of the interface is important. This is generally the trouble of all industrial systems:it is not always easy to quickly understand the situation. It is important how much data is visible in the system, the number of parameters from the node, the ability of the system to operate with a large volume and amount of data. Setting up dashboards, built-in model of the device itself, scene editor (to draw layouts in production).
Let's give a couple of examples of what this gives in practice.
- - , . 10 % . , , , . , , 35 % , . — « ». : , .
- , , . , , . , ( CAN-). , (, , .) «», . — 50 %: , — « », . . , ( , / . .).
- — . . , , , . : / , , , , Big Data, , , « ». — 80 %, ( — , — , ), ( , , .).
Actually, what I wanted to say: today, with a ready-made platform (for example, ours), you can set up monitoring very quickly and easily. This does not require changes in the equipment (or minimal, if there are still no sensors and data transmission), this does not require implementation costs and individual specialists. You just need to study the issue, spend a couple of days to understand how it works, and a few weeks on approvals, a contract and the exchange of data about protocols. And after that, you will have accurate data from all devices. And all this can be done all over the country with the support of the Technoserv integrator, that is, we guarantee a good level of reliability, not typical for a startup.
In the next post, I'll show you how this looks from the vendor side, using an example of one implementation.