As we made the system for mobile rounds in SIBUR
When it comes to the coordinated work of any technically complex production, the importance of safety is difficult to overestimate. And if we are talking about the petrochemical sphere, all the more so. Here, security involves a whole range of activities: access control, specially guarded perimeters, hungry dogs, video surveillance, as well as the satisfactory condition of technical hubs. We will talk about these nodes today.
Complex mechanisms and devices, even within just one platform set. Composite valves and plugs, pumps, piping, fire extinguishing devices, electronics - all this must be monitored, each node must have certain parameters at the right time: the pressure in the pipes, the temperature of the node, the degree of opening of any plug and the like. Of course, a number of the most critical parameters are controlled by electronics, but where it is automatically difficult to do this, the good old rounds with feet come into play.
So while at our facilities, the crawler finishes drinking tea, takes a walkie-talkie with him to communicate with colleagues, a notebook to record any defects found or deviations from the norm, is stored with patience and good mood and goes on a hike around the site. If he notices any critical oddities, he reports them by radio, after which measures are taken to eliminate them. And then, after completing the detour, he goes to his workplace and for some time rewrites all the detected jambs into a general report. Hands in paper.
Of course, a lot of time is spent on all this paper work, taking into account the total number of shifts, the frequency of detours and the speed of writing individual individuals. But then the handwriting must also be disassembled. Therefore, we decided to make life easier for walkers and ourselves by writing an application for mobile bypasses.
The fact that it will be easier for the line inspector is understandable, because you no longer have to write everything down in your notebooks with your hands, and then waste time creating a report. Any incident noticed by him is entered using a mobile application, and the system immediately stitches it into a general report in a readable format.
And another plus for the company is in reducing equipment downtime at the site. In the current reality, 1 hour of idle time of petrochemical production of average capacity is several million rubles. An amount that can obviously be spent with more benefit than disconnecting part of the site and watching the restoration work, glancing at the clock.
It is also easier for shift supervisors - it’s immediately clear how thoroughly and thoroughly the next round was made (and whether it was done in principle), what defects were found, who was to blame and what to do. If something happens - now the management can immediately give the lineman the necessary instructions in the chat application (“Sanya, twist that thing more tightly, and then suddenly something”).
Actually, these were the main pains that we tried to solve.
3r3188. Smartphone app and 3r3189.
Approximately 15 people worked on the application, if you count everything as a whole - backend, frontend, mobile application, design.
Backend decided to do on .NET Core, the front on reactjs, well, where do without Kotlin and Java.
Right now there is a working pilot in one of our sites - there are
at the line inspectors.
A smartphone looks like this not so much because the crawler can drop it, beat them with a pair of nails or neutralize the perimeter intruder with an accurate throw, but because one of the main requirements for electronic devices on the site is explosion-proof, that is, the device should not become a source of explosion (not create spark and the like). After all, anything can happen - somewhere there will be a release of gas, which in itself is not so dangerous, until someone nearby wants to smoke, weld one piece of iron to another piece of iron, or someone for some reason does not short the mobile the rain. The consequences are pretty obvious.
Therefore, the main thing on the site is to move against any threat, no matter how incredible it may seem. By the way, for the same reason, both Bluetooth beacons and NFC tags do not look like laconic beacons familiar to everyone, but like this:
The device works for traversal on the standard Android, respectively, the application we wrote for this platform. Thanks to the app available:
3r3115. authorization of the employee conducting the bypass using staff NFC tags (the employee’s badge with a tag is attached to the smartphone, the smartphone understands who is replacing); 3r3116.
3r3115. a shift screen with a report on defects found and their description (you can take pictures on a smartphone and provide them with burning descriptions); 3r3116.
3r3115. statistics on the work performed (the shift manager sets specific tasks for the detour that must be completed, something can fly in the process of detour already); 3r3116.
3r3115. the composition of the shift (a list of colleagues and those who conducted the previous round); 3r3116.
3r3115. fixed defects (time of problem detection, equipment name and its code, type of problem, photo, equipment status, etc.); 3r3116.
3r3115. chat for quick problem solving; 3r3116.
3r3115. full report on the bypass (elapsed time, etc.). 3r3116.
We also thought about the possibility of making history during the crawl process, but we decided that for now it is not worth it.
On average, there are 8 people in one shift, and there are 4 shifts themselves. We sharpened the system for an average capacity of 2500 people (because now it’s a pilot on one site, and we now have 22 sites and 150 installations).
The site, equipment and necessary zones are hung with BT-beacons and NFC-tags. In some places, in order for the perimeter to be marked as proven, Bluetooth is enough, and somewhere you need to use NFC. Why is that? Because there are certain types of equipment, for checking of which it is enough just to enter the range of the BT-beacon (it’s enough to see that the checked thing still exists in principle at the same place and it hasn’t been blown away), and other equipment requires more careful checking, using precision measuring instruments, fixing parameters and indicators.
Therefore, the employee must touch the NFC-tag of the equipment being checked by the smartphone, so that the system considers this to be a check.
In addition, at each beacon we sewed up a list of checks that need to be carried out with the equipment tied to the beacon. The employee enters the radius of the BT-beacon of the equipment and receives the checklist in the application with what exactly needs to be checked for this piece of iron. Same with the NFC tag. He touched the equipment - the checklist came to the smartphone - he carried out checks. For example, he attached a smartphone to the pump - and received a list: “Check temperature”, “Check pressure” and other parameters.
Accordingly, as soon as an employee entered the BT-beacon zone, the guide is marked with green in the diagram (that is, the employee was there and examined this node), and in the case of an NFC tag, the employee notes each manually checked checklist.
With this we solve the problem of the employee’s forgetfulness (nevertheless, a person can overwork and spend on the device not 12 necessary checks, but 1? for example, but here he always has a list of checks at hand on the smartphone screen), and more clearly we form a report (in the results it will be seen which nodes were inspected and which checks were performed by a specific crawler).
Since it turns out that almost everything is being done through this smartphone, then we are working on the possibility of rejecting walkie-talkies - after all, the crawler does so with a smartphone, why not send voice messages through the application from it. The level of communication at the sites is provided appropriate, so there should be no problems.
This is with regard to the application from the crawler. And this is what it looks like for the shift supervisor.
3r3188. System 3r3189.
In the general layout of the site, management sees the marked areas and each sensor corresponding to the equipment that needs to be checked. As soon as the crawler marks the perimeter or piece of hardware checked with a smartphone, the corresponding section on the diagram is colored green.
We wrote a convenient dashboard so that everything could be conveniently monitored, and generate reports, as well as set new tasks for the surveyors directly during the detour (sometimes there is such a need).
We have achieved the well-coordinated work of this whole business thanks to the microservice architecture. All this looks like this (and we'll talk more about that later):
Full text search on backend done on Elasticsearch.
3r3188. What then
Now the main problems that have led to the creation of the system, we have decided, and we can attach additional ruches to it. For example, we divide the bases to speed up the overall operation of the system.
We also want to pick up the possibility of filling out full-fledged repair orders and tracking their execution.
By itself, we will close a number of bugs. Now, for example, sometimes the crawlers complain that the permissions necessary for the application to work are being dropped from mobile phones.
In general, the pilot succeeded quite well, even though he did not go out to collect the most accurate statistics of incidents - for example, the trackman walked around the site, saw that one of the plugs had become loose, just adjusted on the move and went further, saying, “What the hell is this? to contribute. " That is, frank little things are always corrected on the go, but not always included in the report. But we want to fix every little thing.
The main thing is that the change in useful time has changed for the better.
So far this is all data on the basis of which we can build statistics, for the pilot is a pilot, but in general, everyone is happy.
It may be interesting
German Rottweiler Puppy for sale