Как мы сделали систему для мобильных обходов в СИБУР

Когда речь идет о слаженной работе любого технически сложного производства, значение безопасности переоценить сложно. А если мы говорим о нефтехимической сфере — тем более. Здесь обеспечение безопасности затрагивает целый комплекс мероприятий: пропускной режим, особо охраняемые периметры, голодные собаки, видеонаблюдение, а также удовлетворительное состояние технических узлов. Именно об этих узлах мы сегодня поговорим.

egrtxvlzbbicixrizit2_-ls7jy.jpeg

Сложных механизмов и устройств даже в рамках всего лишь одной площадки множество. Составные вентили и заглушки, насосы, трубопроводы, устройства пожаротушения, электроника — за всем этим надо следить, у каждого узла в нужный момент времени должны быть определенные параметры: давление в трубах, температура узла, степень открытия какой-либо заглушки и тому подобное. Конечно, ряд самых критичных параметров контролируется электроникой, но там, где это сделать автоматически сложно, в игру вступают старые добрые обходы ногами.

Так пока и у нас на объектах — обходчик заканчивает пить чай, берет с собой рацию для связи с коллегами, блокнот для записи возможных найденных дефектов или отклонений от нормы, запасается терпением и хорошим настроением и отправляется в пеший поход по площадке. Если замечает какие-то критичные странности, сообщает о них по рации, после чего принимаются меры для их устранения. А затем, завершив обход, идет на свое рабочее место и еще какое-то время переписывает все обнаруженные косяки в общий отчет. Руками, в бумагу.
Само собой, времени на всю эту бумажную работу тратится немало, учитывая общее количество смен, частоту обходов и скорость письма отдельно взятых личностей. А ведь потом почерк надо еще и разбирать. Поэтому мы решили облегчить жизнь и обходчикам, и себе, написав приложение для мобильных обходов.

То, что обходчику станет проще — понятно, ведь больше не надо записывать все руками в блокноты, а потом тратить время на формирование отчета. Любой замеченный инцидент вносится им с помощью мобильного приложения, и система сразу же подшивает это в общий отчет в удобочитаемом формате.

А еще один плюс для компании — в сокращении времени простоя оборудования на площадке. В текущих реалиях 1 час простоя нефтехимического производства средней мощности — это несколько млн рублей. Сумма, которую явно можно потратить с большей пользой, чем отключать часть площадки и наблюдать за восстановительными работами, поглядывая на часы.

Да и начальникам смены проще — сразу понятно, насколько подробно и тщательно был совершен очередной обход (и был ли совершен в принципе), какие дефекты были обнаружены, кто виноват и что делать. Если что вдруг — теперь руководство сразу может отдать обходчику необходимые распоряжения в чате приложения («Саня, закрути-ка вон ту штуку поплотнее, а то вдруг чего»).

Собственно, это и были основные боли, которые мы пытались решить.

Приложение и смартфон


Над приложением трудились примерно 15 человек, если считать все целиком — backend, frontend, мобильное приложение, дизайн.

Backend решили делать на .NET Core, фронт на reactjs, ну и куда же без Kotlin и Java.

Прямо сейчас идет рабочий пилот в рамках одной из наших площадок — там у обходчиков вот такие железки:

bta8w8bw4ouyxmnsrquxa7mhmsw.jpeg

1gbx77l54zjcar7acvfhgzww0mc.jpeg

Смартфон так выглядит не столько потому, что обходчик может его уронить, забить им пару гвоздей или нейтрализовать нарушителя периметра метким броском, а потому, что одно из основных требований к электронным девайсам на площадке — взрывозащищенность, то есть устройство не должно становиться источником взрыва (не создавать искру и подобное). Ведь случиться может всякое — где-нибудь произойдет выброс газа, который сам по себе не так опасен, пока кто-то поблизости не захочет закурить, приварить одну железку к другой железке, или у кого-то по какой-то причине не коротнет мобилка под дождем. Последствия довольно очевидны.

Поэтому главное на площадке — перебдеть в отношении любой угрозы, какой бы невероятной она ни казалась. Кстати, по этой же причине у нас и Bluetooth-маяки и NFC-метки выглядят не как привычные всем лаконичные биконы, а вот так:

feejm_pd6osjifujfmnlowq51xo.jpeg

s6bmdyr6i6p-6ejuokbyozjjh8w.jpeg

Работает устройство для обходов на стандартном Android, соответственно, приложение мы писали для этой платформы. Благодаря приложению доступны:

  • авторизация сотрудника, проводящего обход, с помощью NFC-метки персонала (к смартфону прикладывается пропуск сотрудника с меткой, смартфон понимает, кто сейчас выходит на смену);
  • экран смены с отчетом о найденных дефектах и их описание (можно делать фотки на смартфон и снабжать их животрепещущими описаниями);
  • статистика по выполненным работам (начальник смены ставит конкретные задачи на обход, которые надо выполнить, что-то может прилететь пушем уже в процессе обхода);
  • состав смены (список коллег и тех, кто проводил предыдущий обход);
  • зафиксированные дефекты (время обнаружения проблемы, название оборудования и его код, вид проблемы, фото, статус оборудования и прочее);
  • чат для оперативного решения проблем;
  • полный отчет об обходе (затраченное время и прочее).

Думали еще над возможностью делать history в процессе обхода, но решили, что пока не стоит.

В среднем в одной смене 8 человек, а самих смен — 4. Мы заточили систему под среднюю ёмкость в 2500 человек (потому что сейчас это пилот на одной площадке, а у нас сейчас 22 площадки и 150 установок).

Обход


Площадка, оборудование и нужные зоны увешаны BT-маяками и NFC-метками. В некоторых местах для того, чтобы периметр отметился как проверенный, достаточно Bluetooth, а где-то необходимо использование NFC. Почему так? Потому что есть определенные виды оборудования, для проверки которых достаточно просто войти в радиус действия BT-маяка (достаточно посмотреть, что проверяемая штуковина в принципе еще существует на том же месте и ее не сдуло), а другое оборудование требует более тщательной проверки, с использованием точных измерительных приборов, фиксации параметров и показателей.

Поэтому сотрудник должен коснуться смартфоном NFC-метки проверяемого оборудования, чтобы система засчитала это за проверку.

Кроме этого, в каждый маячок мы зашили перечень проверок, которые надо провести именно с привязанным к маячку оборудованием. Сотрудник входит в радиус BT-маяка оборудования и получает в приложение чеклист с тем, что конкретно нужно проверить для данной железки. То же самое с NFC-меткой. Коснулся оборудования — в смартфон пришел чеклист — провел проверки. Например, приложил смартфон к насосу — и получил список: «Проверить температуру», «Проверить давление» и иные параметры.

Соответственно, как только сотрудник зашел в зону BT-маяка, на схеме у руководства такая зона помечается зеленым цветом (то есть, сотрудник тут был и данный узел осмотрел), а в случае с NFC-меткой сотрудник отмечает каждую проведенную проверку вручную в списке.

Этим мы решаем и проблему забывчивости сотрудника (все же, человек может переутомиться и провести над устройством не 12 нужных проверок, а 11, к примеру, а тут у него всегда список проверок под рукой на экране смартфона), и яснее формируем отчет (в результатах будет видно, какие узлы были осмотрены и какие именно проверки были проведены конкретным обходчиком).

Раз получается так, что почти всё у нас сейчас делается через этот смартфон, то мы прорабатываем возможность отказа и от раций — в конце концов, обходчик так и так со смартфоном, почему бы еще с него и не отправлять голосовые сообщения через приложение. Уровень связи на площадках обеспечивается соответствующий, так что проблем быть не должно.

Это что касается приложения со стороны обходчика. А вот как это выглядит для начальника смены.

Система


На общей схеме площадки руководство видит размеченные участки и каждый датчик, соответствующий оборудованию, которое надо проверить. Как только обходчик помечает периметр или железку проверенной с помощью смартфона, соответствующий участок на схеме закрашивается зеленым.

Мы написали удобный дашборд для того, чтобы можно было все удобно мониторить, а формировать отчеты, а также ставить обходчикам новые задачи прямо во время обхода (иногда бывает и такая необходимость).

Слаженной работы всего этого дела мы добились благодаря микросервисной архитектуре. Выглядит все это вот так (и об этом мы еще расскажем подробнее):

zwdtscsiqlxjjnilmzri_syg7h0.jpeg

Полнотекстовый поиск на backend сделали на Elasticsearch.

Что потом


Сейчас главные проблемы, ставшие поводом к созданию системы, мы решили, и можно навешивать на нее дополнительные рюшечки. Например, разделим базы, чтобы ускорить общую работу системы.

А ещё хотим подцепить возможность оформления полноценных заявок на ремонт и отслеживания их исполнения.

Само собой, закроем ряд багов. Сейчас, например, иногда обходчики жалуются, что с мобилок слетают необходимые для работы приложения разрешения.

В целом пилот вполне себе удался, хоть пока и не выходит собирать максимально четкую статистику инцидентов — например, шел обходчик по площадке, увидел, что одна из заглушек разболталась, просто поправил на ходу и пошел дальше, мол «Фигня какая, чего это в список вносить». То есть откровенные мелочи всегда исправляются на ходу, но не всегда вносятся в отчет. Но мы хотим фиксировать каждую мелочь.

Главное — в лучшую сторону изменилось полезное время смены.

Пока это все данные, на основе которых можем строить статистику, ибо пилот — это пилот, но в общем и целом — все довольны.

Включая обходчиков.

© Habrahabr.ru