Как мы сделали систему для мобильных обходов в СИБУР
Когда речь идет о слаженной работе любого технически сложного производства, значение безопасности переоценить сложно. А если мы говорим о нефтехимической сфере — тем более. Здесь обеспечение безопасности затрагивает целый комплекс мероприятий: пропускной режим, особо охраняемые периметры, голодные собаки, видеонаблюдение, а также удовлетворительное состояние технических узлов. Именно об этих узлах мы сегодня поговорим.
Сложных механизмов и устройств даже в рамках всего лишь одной площадки множество. Составные вентили и заглушки, насосы, трубопроводы, устройства пожаротушения, электроника — за всем этим надо следить, у каждого узла в нужный момент времени должны быть определенные параметры: давление в трубах, температура узла, степень открытия какой-либо заглушки и тому подобное. Конечно, ряд самых критичных параметров контролируется электроникой, но там, где это сделать автоматически сложно, в игру вступают старые добрые обходы ногами.
Так пока и у нас на объектах — обходчик заканчивает пить чай, берет с собой рацию для связи с коллегами, блокнот для записи возможных найденных дефектов или отклонений от нормы, запасается терпением и хорошим настроением и отправляется в пеший поход по площадке. Если замечает какие-то критичные странности, сообщает о них по рации, после чего принимаются меры для их устранения. А затем, завершив обход, идет на свое рабочее место и еще какое-то время переписывает все обнаруженные косяки в общий отчет. Руками, в бумагу.
Само собой, времени на всю эту бумажную работу тратится немало, учитывая общее количество смен, частоту обходов и скорость письма отдельно взятых личностей. А ведь потом почерк надо еще и разбирать. Поэтому мы решили облегчить жизнь и обходчикам, и себе, написав приложение для мобильных обходов.
То, что обходчику станет проще — понятно, ведь больше не надо записывать все руками в блокноты, а потом тратить время на формирование отчета. Любой замеченный инцидент вносится им с помощью мобильного приложения, и система сразу же подшивает это в общий отчет в удобочитаемом формате.
А еще один плюс для компании — в сокращении времени простоя оборудования на площадке. В текущих реалиях 1 час простоя нефтехимического производства средней мощности — это несколько млн рублей. Сумма, которую явно можно потратить с большей пользой, чем отключать часть площадки и наблюдать за восстановительными работами, поглядывая на часы.
Да и начальникам смены проще — сразу понятно, насколько подробно и тщательно был совершен очередной обход (и был ли совершен в принципе), какие дефекты были обнаружены, кто виноват и что делать. Если что вдруг — теперь руководство сразу может отдать обходчику необходимые распоряжения в чате приложения («Саня, закрути-ка вон ту штуку поплотнее, а то вдруг чего»).
Собственно, это и были основные боли, которые мы пытались решить.
Приложение и смартфон
Над приложением трудились примерно 15 человек, если считать все целиком — backend, frontend, мобильное приложение, дизайн.
Backend решили делать на .NET Core, фронт на reactjs, ну и куда же без Kotlin и Java.
Прямо сейчас идет рабочий пилот в рамках одной из наших площадок — там у обходчиков вот такие железки:
Смартфон так выглядит не столько потому, что обходчик может его уронить, забить им пару гвоздей или нейтрализовать нарушителя периметра метким броском, а потому, что одно из основных требований к электронным девайсам на площадке — взрывозащищенность, то есть устройство не должно становиться источником взрыва (не создавать искру и подобное). Ведь случиться может всякое — где-нибудь произойдет выброс газа, который сам по себе не так опасен, пока кто-то поблизости не захочет закурить, приварить одну железку к другой железке, или у кого-то по какой-то причине не коротнет мобилка под дождем. Последствия довольно очевидны.
Поэтому главное на площадке — перебдеть в отношении любой угрозы, какой бы невероятной она ни казалась. Кстати, по этой же причине у нас и Bluetooth-маяки и NFC-метки выглядят не как привычные всем лаконичные биконы, а вот так:
Работает устройство для обходов на стандартном Android, соответственно, приложение мы писали для этой платформы. Благодаря приложению доступны:
- авторизация сотрудника, проводящего обход, с помощью NFC-метки персонала (к смартфону прикладывается пропуск сотрудника с меткой, смартфон понимает, кто сейчас выходит на смену);
- экран смены с отчетом о найденных дефектах и их описание (можно делать фотки на смартфон и снабжать их животрепещущими описаниями);
- статистика по выполненным работам (начальник смены ставит конкретные задачи на обход, которые надо выполнить, что-то может прилететь пушем уже в процессе обхода);
- состав смены (список коллег и тех, кто проводил предыдущий обход);
- зафиксированные дефекты (время обнаружения проблемы, название оборудования и его код, вид проблемы, фото, статус оборудования и прочее);
- чат для оперативного решения проблем;
- полный отчет об обходе (затраченное время и прочее).
Думали еще над возможностью делать history в процессе обхода, но решили, что пока не стоит.
В среднем в одной смене 8 человек, а самих смен — 4. Мы заточили систему под среднюю ёмкость в 2500 человек (потому что сейчас это пилот на одной площадке, а у нас сейчас 22 площадки и 150 установок).
Обход
Площадка, оборудование и нужные зоны увешаны BT-маяками и NFC-метками. В некоторых местах для того, чтобы периметр отметился как проверенный, достаточно Bluetooth, а где-то необходимо использование NFC. Почему так? Потому что есть определенные виды оборудования, для проверки которых достаточно просто войти в радиус действия BT-маяка (достаточно посмотреть, что проверяемая штуковина в принципе еще существует на том же месте и ее не сдуло), а другое оборудование требует более тщательной проверки, с использованием точных измерительных приборов, фиксации параметров и показателей.
Поэтому сотрудник должен коснуться смартфоном NFC-метки проверяемого оборудования, чтобы система засчитала это за проверку.
Кроме этого, в каждый маячок мы зашили перечень проверок, которые надо провести именно с привязанным к маячку оборудованием. Сотрудник входит в радиус BT-маяка оборудования и получает в приложение чеклист с тем, что конкретно нужно проверить для данной железки. То же самое с NFC-меткой. Коснулся оборудования — в смартфон пришел чеклист — провел проверки. Например, приложил смартфон к насосу — и получил список: «Проверить температуру», «Проверить давление» и иные параметры.
Соответственно, как только сотрудник зашел в зону BT-маяка, на схеме у руководства такая зона помечается зеленым цветом (то есть, сотрудник тут был и данный узел осмотрел), а в случае с NFC-меткой сотрудник отмечает каждую проведенную проверку вручную в списке.
Этим мы решаем и проблему забывчивости сотрудника (все же, человек может переутомиться и провести над устройством не 12 нужных проверок, а 11, к примеру, а тут у него всегда список проверок под рукой на экране смартфона), и яснее формируем отчет (в результатах будет видно, какие узлы были осмотрены и какие именно проверки были проведены конкретным обходчиком).
Раз получается так, что почти всё у нас сейчас делается через этот смартфон, то мы прорабатываем возможность отказа и от раций — в конце концов, обходчик так и так со смартфоном, почему бы еще с него и не отправлять голосовые сообщения через приложение. Уровень связи на площадках обеспечивается соответствующий, так что проблем быть не должно.
Это что касается приложения со стороны обходчика. А вот как это выглядит для начальника смены.
Система
На общей схеме площадки руководство видит размеченные участки и каждый датчик, соответствующий оборудованию, которое надо проверить. Как только обходчик помечает периметр или железку проверенной с помощью смартфона, соответствующий участок на схеме закрашивается зеленым.
Мы написали удобный дашборд для того, чтобы можно было все удобно мониторить, а формировать отчеты, а также ставить обходчикам новые задачи прямо во время обхода (иногда бывает и такая необходимость).
Слаженной работы всего этого дела мы добились благодаря микросервисной архитектуре. Выглядит все это вот так (и об этом мы еще расскажем подробнее):
Полнотекстовый поиск на backend сделали на Elasticsearch.
Что потом
Сейчас главные проблемы, ставшие поводом к созданию системы, мы решили, и можно навешивать на нее дополнительные рюшечки. Например, разделим базы, чтобы ускорить общую работу системы.
А ещё хотим подцепить возможность оформления полноценных заявок на ремонт и отслеживания их исполнения.
Само собой, закроем ряд багов. Сейчас, например, иногда обходчики жалуются, что с мобилок слетают необходимые для работы приложения разрешения.
В целом пилот вполне себе удался, хоть пока и не выходит собирать максимально четкую статистику инцидентов — например, шел обходчик по площадке, увидел, что одна из заглушек разболталась, просто поправил на ходу и пошел дальше, мол «Фигня какая, чего это в список вносить». То есть откровенные мелочи всегда исправляются на ходу, но не всегда вносятся в отчет. Но мы хотим фиксировать каждую мелочь.
Главное — в лучшую сторону изменилось полезное время смены.
Пока это все данные, на основе которых можем строить статистику, ибо пилот — это пилот, но в общем и целом — все довольны.
Включая обходчиков.
