Нас позвали в цех решить задачу. Приходим — там тишина, люди ходят мрачные. Оказалось, недавно пришлось экстренно вернуть обратно в ремонт более 1000 колёсных пар, потому что не нашлось их диагностических протоколов. Это очень дорого. И больно.

Причину быстро нашли. Там был ненадёжный элемент, отвечающий за взаимодействие между буксами и вибростендом.

Человек. Реальный человеческий фактор в системе диагностики.



В вагоне колёса жёстко сидят на одной оси, и у каждой есть букса — подшипниковый узел, который позволяет колёсной паре вращаться.

Букса проверяется вибродиагностикой. На вибростенде её раскручивают до 300 оборотов в минуту и датчики слушают, нет ли странных звуков. По результатам формируется протокол, где указано, пригодна ли букса. По регламенту в конце рабочего дня оператор должен распечатать протоколы за смену и подшить их в архивную папку. Для этого нужно подойти к стенду, авторизоваться, выбрать период, сформировать сводный файл отчёта (или единичный отчёт) и нажать кнопку «Печать». Все протоколы хранятся в бумажном виде — в тех самых архивных папках, а ещё в закрытой базе данных стенда.

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

А если в грузовом составе с такой колёсной парой под вагоном что-то пойдёт не так, это уже не просто накладка, а огромная проблема, которую разбирать будут очень серьёзные люди.

После инцидента с теми самыми 1000 колёсными парами отдел качества обнаружил, что на заводе есть айтишники. И мы даже умеем правильно хранить документы. Собственно, из-за этой суперспособности нас и позвали.




Знакомьтесь: колёсная пара. Штуковина сбоку от колеса — та самая букса

Что может пойти не так на вибродиагностике

Чтобы прочно соединить колёсную пару с вагоном, подшипник нужно цеплять не внутри, а на внешней стороне оси, за колёсами. Именно через такие буксовые узлы с подшипниками тележки опираются на колёсные пары и обеспечивают движение вагона.



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

Поэтому при любом подозрительном шуме буксу признают негодной.

После диагностики вибростенд выдаёт протокол, который решает судьбу колёсной пары. На его основании колёсную пару либо бракуют в повторный ремонт, либо отправляют под ближайший вагон. В хорошем смысле, конечно.

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

Помните, что после проверки стенд выдаёт протоколы? Так вот: выдаёт он их в самом прямом смысле. Сотрудник подходит к стенду, нажимает кнопку, протоколы за смену печатаются. Затем их подшивают в папку и ставят на полку среди других папок. Централизованного контроля за этим — ноль. Мастер мог просто забыть распечатать, заболеть, не досмотреть, потерять, в конце концов. Конечно, протоколы хранятся и в базе стенда. Но если стенд засбоил и полетела база данных, то протоколы терялись безвозвратно. ПО стенда периодически делает бэкап базы, но в полной мере контролировать этот процесс мы не могли, разработчики стенда внешнего доступа к базе не предусматривали.

И вот приехала проверка к нашим заказчикам, в одно из вагоноремонтных депо

И тут обнаружилось, что для нескольких колёсных пар, которые уже отправили в работу, нет протоколов — ни в бумажном виде, ни в базе стенда. Проверили другие пары. И в общей сложности нашли 1504 детали, диагностика которых не была подтверждена протоколом.

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

По итогу разбирательств пришлось оперативно возвращать колёсные пары на повторную проверку — разумеется, за счёт компании. И суть-то не в том, что колёса проверены не были — не было протоколов. Ну а как ещё узнать, что колёса проверены?

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

Задача простая, но…

Надо сделать так, чтобы отчёты со всех вибростендов автоматически попадали в единую электронную базу. По этой базе уже можно смотреть, соответствует ли количество проверенных пар количеству поступивших, какие результаты были у каждой конкретной проверки и т.д. Вроде бы всё здорово, но в процессе мы столкнулись с неожиданными проблемами.

Во-первых, нельзя просто взять и подключить стенд к сети. Он стоит в центре огромного цеха, повсюду ездят кран-балки, катаются колёса, везде железо и бетон. И по вайфаю тоже нельзя, потому что помехи и служба безопасности.

Во-вторых, нет какого-то универсального стенда для проверки. На предприятии их четыре типа, и каждый выгружает свой протокол с разным набором данных.

В-третьих, даже на одном типе стендов могут стоять разные версии ПО, иногда даже от разных производителей (!).

В-четвёртых, на старых стендах стояло старое оборудование, работало на архаичном железе, которое могло тянуть, например, Windows XP. А всё, что новее, тянуть не могло.

В-пятых, некоторые стенды были укомплектованы обычными ПК, а некоторые промышленными компьютерами. Это такая закрытая коробка, в которую нельзя залезть и, например, добавить туда оперативки или поменять процессор.



Ну и наконец, это цех. Там постоянные вибрации, грязь, масляная взвесь в воздухе. Поэтому комплектующие, которые там стоят, могут барахлить.

Как решали и что получилось

Мы, взвесив все за и против, решили исключить из программы самые старые станки. Им всё равно оставалось недолго, их постепенно выводили из эксплуатации. И тратить время на то, чтобы адаптировать программу под них, было нерационально.

Затем мы внимательно посмотрели на оставшиеся стенды и составили ТЗ для каждого типа: как нужно доработать ПО, чтобы оно могло взаимодействовать с нашей программой и отправлять нам в единую систему протоколы. Эти ТЗ разослали компаниям-производителям, чтобы они — не бесплатно, конечно, выпустили нужные обновления. В итоге мы получили стенды, которые могут формировать типовой протокол в XML.

Проблему нестабильности соединения тоже решили. Отчёты не отправляются в единую базу автоматически. Они хранятся на компьютере самого стенда, а центральная система периодически опрашивает стенды через Kubernetes и Apache Airflow и забирает все протоколы в базу PostgreSQL. Если отчёт сформировался с ошибкой, стенд не отвечает или слишком давно не посылал файлы, на панели у разработчика загорается красный сигнал, а на почту прилетает уведомление.

Полученные данные экспортируются в корпоративную 1С (потому что подавляющая часть пользователей ОМК «Стальной путь» работает в 1С ERP), и в любой момент можно посмотреть, сколько колёсных пар проверили, в какой период и с каким результатом. Попутно вместе с коллегами мы провели объёмную работу по разработке АРМ в 1С.


Так выглядит схема, по которой мы собираем отчёты


А так выглядит конвейер данных на Airflow с мониторингом выполнения задач

Заодно

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

А люди, как вы помните, стремятся минимизировать свою рабочую нагрузку. И есть искушение загнать одну пару на стенд, а потом проверять её несколько раз подряд, просто вручную забивая в систему новые номера. Старые типы стендов позволяют хитрить подобным образом, новые распознают подлог, но и здесь голь на выдумки хитра, операторы, подвешивая магниты и прочие не имеющие отношения к КП предметы, могут повлиять на данные диагностики. Здесь мы подошли просто — установили камеры видеонаблюдения над всеми вибродиагностиками и, периодически просматривая записи, можем выявлять подобных «фокусников».

Итоги: до и после

Итоги такие: процесс стал прозрачным, каждая колёсная пара отслеживается. Проверять удобнее, рыться в бумажных архивах не надо, контроль автоматизирован, все несоответствия видны в режиме реального времени. Появилась резервная база отчётов, можно не переживать, что со стендом что-то случится и мы потеряем все протоколы.

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

Сейчас идёт этап ОПЭ. Систему мы пока подключили в пилотном режиме на 50% стендов, постепенно подключаем новые. В результате выявили колёсные пары, у которых был «абонемент» на катание, но по факту все колёсные пары прошли диагностику.

В общем, если коротко:

Было:

• Протоколы хранились локально на стендах и на бумаге.
• Контроль проводился только при проверке.
• Операторы могли повторно вносить одни и те же данные.

Стало:

• Все протоколы централизованы и доступны в реальном времени.
• В 1С видна вся диагностика с возможностью ежедневного анализа.
• Исключены случаи многократного использования одной проверки.

Что дальше

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

Количество работы на местах, конечно, выросло, и не все сотрудники этим довольны. Компании наверняка придётся пересмотреть загрузку персонала. Но когда речь идёт о безопасности на железнодорожных путях, другого пути просто нет.

Ещё раз отмечу, что это произошло в одном локальном депо из нескольких десятков, и этот единичный случай показал, что систему можно улучшить. С него мы и начали раскатывать решение. И в других продолжим, хотя в разных депо разные принципы хранения документов и регламентов.