How we made a system for mobile rounds at 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, having completed 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, looking at the clock.
And it is 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 application chat (“Sanya, twist that thing more tightly, and then suddenly something”).
Actually, these were the main pains that we tried to solve.
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, and so far without Kotlin and Java.
Right now there is a working pilot in one of our sites - there are the following pieces of equipment at the checkpoints:
The 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 implications 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:
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 have 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 the 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 counts this for checking.
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 - conducted 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, on the scheme for the management, such zone is marked in green (that is, the employee was here and examined this node), and in the case of an NFC tag, the employee notes each manual check in the list.
By 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 11, 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 radios as well - in the end, 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.
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. It looks like this (and we'll talk more about that later):
Full text search on backend done on Elasticsearch.
Now the main problems that have led to the creation of the system, we have decided, and you can hang on it additional ruches. 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 requests 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 the mobile phones.
In general, the pilot was quite successful, even though he does not go out to collect the most accurate incident statistics - for example, the trackman was walking around the site, he 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 recorded 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 the pilot, but in general, everyone is happy.
Including walkers.
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, having completed 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, looking at the clock.
And it is 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 application chat (“Sanya, twist that thing more tightly, and then suddenly something”).
Actually, these were the main pains that we tried to solve.
App and smartphone
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, and so far without Kotlin and Java.
Right now there is a working pilot in one of our sites - there are the following pieces of equipment at the checkpoints:
The 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 implications 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:
- 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);
- a shift screen with a report on the defects found and their description (you can take pictures on your smartphone and supply them with burning descriptions);
- statistics on the work performed (the shift manager sets specific tasks for the detour that need to be completed, something can come flying already in the process of detour);
- the composition of the shift (a list of colleagues and those who conducted the previous round);
- fixed defects (time of detection of the problem, name of the equipment and its code, type of problem, photo, status of the equipment, etc.);
- chat for quick problem solving;
- full report on the bypass (elapsed time, etc.).
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 have 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).
Bypass
The site, equipment and the 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 counts this for checking.
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 - conducted 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, on the scheme for the management, such zone is marked in green (that is, the employee was here and examined this node), and in the case of an NFC tag, the employee notes each manual check in the list.
By 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 11, 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 radios as well - in the end, 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.
System
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. It looks like this (and we'll talk more about that later):
Full text search on backend done on Elasticsearch.
What then
Now the main problems that have led to the creation of the system, we have decided, and you can hang on it additional ruches. 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 requests 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 the mobile phones.
In general, the pilot was quite successful, even though he does not go out to collect the most accurate incident statistics - for example, the trackman was walking around the site, he 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 recorded 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 the pilot, but in general, everyone is happy.
Including walkers.
Source: https://habr.com/ru/post/428353/
All Articles