Hey Habr! Our team monitors machines and installations all over the country. In fact, we provide an opportunity for the manufacturer not to drive the engineer once again, when “oh, it’s all broken”, but in fact, you need to press one button. Or when it broke not on the equipment, but nearby.
The basic problem is the following. Here you are producing an oil cracker, or a machine tool for mechanical engineering, or some other device for a plant. As a rule, the sale itself is extremely rarely possible: usually it is 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 SLAs, or something like that.
In fact, this means that you need to send an engineer to the site regularly. As our practice shows, from 30 to 80% of trips are superfluous. 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 a replacement or complex work on the schedule, and he himself divides the compensation in half with someone from the factory. Or he just enjoys relaxing with his mistress (a real case) and therefore likes to travel more often. The factory 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, analysis of protocols and a processing environment with the ability to see and compare everything. Well, with all this there are nuances.
Why can't you do without remote monitoring?
Banally expensive. Business trip for one engineer - at least 50 thousand rubles (airplane, hotel, accommodation, daily allowance). Plus, it is not always possible to break, and the same person may be needed in different cities.
- In Russia, the supplier and consumer are almost always far enough apart. When you sold a product to Siberia, you know nothing about it except what the supplier tells you. Neither how it works, nor in what conditions it is operated, nor, in fact, who pressed which 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.
- Unfounded appeals and claims. That is, your customer, who operates your product, can call, write, complain at any time and say that your thing does not work, it is bad, it is broken, come urgently and fix it. If you are lucky and it’s not just “they didn’t fill up the consumable”, then you knowingly sent a specialist. It often happens that useful work takes less than an hour, and everything else - preparing a business trip, flights, accommodation - all this took a lot of time for an engineer.
- There are clearly unfounded claims, and in order to prove this, you need to send an engineer, draw up an act, go to court. As a result, the process is delayed, and it does not bring anything good either for the customer or for you.
- Disputes arise due to the fact that, for example, the customer misused the product, the customer for some reason has a grudge against you and does not say that your product did not work correctly, not in the modes that are stated in the TOR and in the passport . At the same time, you cannot oppose it or you can, but with difficulty, if, for example, your product somehow logs and records those modes. Breakdowns due to the fault of the customer - this happens all the time. I had a case when an expensive German portal machine broke down due to a collision with a pole. The operator did not bind to zero, and as a result, the machine stopped there. Moreover, the customer quite clearly said: "And we have nothing to do with it." But the information was logged, and it was possible to raise these logs and understand on which control program and as a result of which this very collision occurred. This saved the supplier a very large warranty repair expense.
- The mentioned "gray" schemes are collusion with a service provider. The serviceman goes to the customer constantly one and the same. They say to him: “Listen, Kol, let's know how we will do it: you will write that everything is broken here, we will receive compensation, or you will bring some kind of zip for repair. We will implement all this on the sly, we will share the money. It remains either to believe, or somehow invent some complicated ways to test all these conclusions, confirmations, which does not add either time or nerves, and nothing good happens in this. If you are familiar with how car services deal with warranty fraud and how much complexity this imposes on processes, then you roughly understand the problem.
Well, all the same devices write a log, right? What is the problem?
The problem is that if suppliers more or less understand that the log needs to be constantly written somewhere (or have understood over the past few decades), then the culture has not gone further. The log is often needed to analyze cases with expensive repairs - whether it was an operator error or a real equipment failure.
To pick up the 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 beat 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 with just those industries where monitoring is only getting better).
Our main clients are equipment manufacturers. As a rule, they start to think that it is worth doing some kind of monitoring, either after some major incident, or just looking at the travel bills for the year. But more often than not, we are talking about a major failure with a loss of money or reputation. Progressive leaders who think "no matter what happens" are rare. The fact is that usually the manager gets the old "park" of service contracts, and he sees no point in putting sensors on new hardware, because it will be needed only in a couple of years.
In general, at some point, the roasted rooster still pecks, and the time comes for modifications.
By itself, data transfer is not very scary. The equipment usually already has sensors (or they are installed quite quickly), plus logs are already being written and service events are being noted. All you need to do is start sending. The general practice is to insert some kind of modem, for example, with an embed-SIM, directly into the device from an X-ray machine to an automatic seeder, and send telemetry via a cellular network. Places where there is no 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 read them somehow. In the general case, some kind of system for visualizing and analyzing incidents is needed.
And then we appear on the stage. More precisely, we often appear earlier, because the leaders of the suppliers look at 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: a Siemens ecosystem (very expensive, needed for very large nodes, usually like turbines), self-written mandulas, or one of the 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 us to collect any data from any device using any (well, 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 visual user interface designer.
As a result, we can collect all the data from the manufacturer's device, put it in storage on the server, and collect a dashboard with alerts there.
This is how it looks (here the customer made another 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 they leave them.
Well, the most difficult thing is to predict the failure of nodes according to 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 a payment for downtime.
Summary
This story would sound quite simple: well, they realized that they needed to send data, monitoring and analysis, well, they chose a vendor and implemented it. Well, that's it, everyone is happy. If we are talking about self-written systems in our own factory, then, oddly enough, the systems quickly become unreliable. We are talking about the banal loss of logs, inaccurate data, failures in the 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 transmitting equipment itself that is primary, but the system that allows you to analyze the received data. The convenience of the interface is important. This is generally the misfortune 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, a built-in model of the device itself, a scene editor (to draw layouts in factories).
Let's give a couple of examples of what this gives in practice.
- Here is a global manufacturer of industrial refrigeration equipment used mainly in retail chains. 10% of the company's income comes from the provision of services for the maintenance of its products. It is necessary to reduce the cost of services and generally give the opportunity to normally increase deliveries, because if you sell more, then the existing service system will not cope. We connected directly to the platform of a single service center, modified a couple of modules for the needs of this particular customer, and received a 35% reduction in travel expenses due to the fact that access to service information makes it possible to identify the causes of failure without a service engineer leaving. Data analysis over long time intervals - predict the technical condition and, if necessary, quickly perform “on condition” maintenance. As a bonus, the speed of response to a request has increased: there are fewer trips, engineers began to keep up faster.
- A machine-building company, a manufacturer of electric vehicles used in many cities of the Russian Federation and the CIS. Like everyone else, they want to reduce costs and at the same time predict the technical condition of the city's trolleybus and tram fleets in order to notify technical staff in time. We connected, created algorithms for collecting and transmitting technical data from rolling stock to a single situational center (algorithms are built directly into the drive control system and work with CAN bus data). Remote access to technical condition data, including real-time access to changing parameters (speed, voltage, regenerative energy transfer, etc.) in the “oscilloscope” mode, gave access to remote firmware updates. The result is a 50% reduction in travel costs: direct access to service information provides the ability to identify the causes of failure without a service engineer leaving, and data analysis over long periods of time allows you to predict the technical condition and, if necessary, quickly perform “on condition” maintenance, including objective analysis of emergency situations. Implementation of extended life cycle contracts in full compliance with the requirements of the Customer and on time. Compliance with the requirements of the Operator's Terms of Reference, as well as providing him with new opportunities in terms of controlling the characteristics of consumer service (quality of air conditioning, acceleration / deceleration, etc.).
- The third example is the municipality. We need to save electricity and improve the safety of citizens. Connected a single platform for monitoring, managing and collecting data on connected street lighting, remote management of the entire infrastructure of public lighting and its maintenance from a single control panel, providing the following tasks. Features: dim or turn on/off lights remotely, individually or in a group, automatically notify city services of failures in lighting points for more efficient maintenance planning, provide real-time data on energy consumption, provide powerful analytical tools to monitor and improve the street lighting system based on Big Data, providing data on traffic, air conditions, integration with other Smart City subsystems. Results - reduction of electricity consumption for street lighting by up to 80%, increased safety for residents through the use of intelligent lighting control algorithms (a person walking down the street - turn on the light for him, a person at the crossing - turn on brighter lighting so that it can be seen from afar), providing the city additional services (charging electric vehicles, providing advertising content, video surveillance, etc.).
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 for approvals, an agreement and the exchange of data about protocols. And after that, you will have accurate data from all devices. And all this can be done throughout the country with the support of the integrator Technoserv, that is, we guarantee a good level of reliability, uncharacteristic for a startup.
In the next post, I will show how this looks from the supplier's side, using an example of one implementation.
Source: habr.com