Мобильный мир давно победил десктопный и в быту, и на производстве. Нет времени инструктировать рабочих на брифингах, а потом отправлять их в цеха с распечатками: каждая секунда простоя — это потерянные деньги. Теперь ремонтник ходит по цеху среди тонн металла, проводит осмотр оборудования или устраняет неисправности. В этом ему помогает терминал, которым он сканирует NFC-метки, QR-коды на оборудовании, делает фото и видео. Время от времени сканирует детали терминалом. Далее — рассказ о том, что находится внутри терминала, а также как у нас получилось сделать приложение для ремонтников и с чем пришлось столкнуться по ходу.
Ремонтные бригады разделены на группы планирования: электриков, автоматчиков, гидравликов и т. д. Каждый занимается своим направлением, а вместе они охватывают всё металлургическое оборудование, которое есть на заводе.
До появления мобильного приложения всё заносилось на десктопе, а ремонтник получал распечатанное задание и карту обхода или устное: «Иди туда, сделай то-то».
А проверки бывают разные, и про некоторые нужно много писать. Есть смотровые операции: условно говоря, «подошёл, посмотрел, работает или не работает». Есть более сложные — с внесением измерений параметров с приборов и датчиков, например, термометров. Бывают операции в несколько этапов, которые могут требовать расходных материалов. Ещё есть длительные «остановочные» ремонты — это уже про подвижные составы и крупное оборудование.
Закончив обход, сотрудник шёл в рабочую комнату и заносил все данные в компьютер.
Это было не только долго, но ещё и неудобно: была большая вероятность совершить ошибку при перепечатывании данных.
Четыре года назад мы разработали первую версию мобильного приложения, чтобы ускорить все эти процессы. Стало быстрее, но всё ещё неудобно. В основном потому, что устройства (такие специальные защищённые телефончики) постоянно теряли сеть, так как не было pLTE, приложение не могло нормально синхронизироваться с сервером плюс у него были минимальный функционал и не очень удобный дизайн.
В итоге мы собрались, почитали отзывы ремонтников, которые ходили с этим по цехам, и переработали приложение. Провели глубокую модернизацию на современном стеке — с новым интерфейсом и упором на юзабилити, автономность, скорость работы.
Первую версию обновлённого приложения мы выпустили в феврале прошлого года. Для начала протестировали его в пилотном режиме в одном цеху, потом охватили всё предприятие, а сейчас докручиваем разные фичи.
Отдельно скажу про те самые защищённые телефончики. Приложение мы писали не для стандартных телефонов, а для специальных терминалов сбора данных на Андроиде (версии 10 и 11). Они защищены от пыли, влаги и ударопрочны, а также оснащены разными интересными опциями типа сканера штрих-кодов или RFID-ридером. На некоторых моделях есть даже ручка, чтобы их было удобнее держать в горизонтальном положении.
Шаг первый: добиваемся автономности
На комбинате во всех цехах есть покрытие сети комбината pLTE, но ввиду критичности системы ремонтов для подстраховки мы сразу реализовали возможность работы в офлайне, чтобы не отвлекаться от основной цели — ремонтов.
Для этого пришлось переработать подход к данным.
Всё устроено так: есть база данных в мастер-системе, где хранится вся информация за последние годы. Сообщения сохраняются до тех пор, пока не переводятся в статус «Удалённые» (это делают вручную). Сообщений много, и перетащить всю базу данных целиком — не вариант. Поэтому мы решили её переработать и передавать частями.
Основная идея — взять небольшой фрагмент базы данных мастер-системы и сегментировать. Сначала — цех, время, группы планирования и так далее. Мы разделили данные на два типа: справочные и оперативные. Справочные данные меняются редко — это каталоги неисправностей, запчастей, оборудования. Всё это заранее структурировано и каталогизировано. Оперативные данные — это заказы на обслуживание и сообщения о поломках, которые часто обновляются.
В мастер-системе мы не стали дробить или таскать эти данные, а реализовали промежуточный бэкенд. Это своего рода слепок базы данных, который поддерживает витрины и агрегаты для мобильных клиентов, собирающие информацию по запросам.
Реализация:
Для мобильного приложения — стандартный Android-набор + библиотека Room.
На бэке СУБД Postgres.
Kafka — для доставки дельты данных.
Пришлось писать свой мини-бэк (который миддл, который бэк), там пришлось учить SQL. Если обмен базы с устройством очень простой, то вот агрегаты на устройстве из локального репозитория строятся очень сложными запросами.
Архитектура — Model-View-Intent, потому что всё в слое с репозиторием.
Как видите, в принципе — никакой rocket science, но и не как обычно для таких задач.
Основные сложности заключались в проектировании решения и работе с временными дельтами.
Синхронизацию сделали максимально простой и понятной — по одной кнопке.
Рабочий утром пришёл, переоделся, взял рабочий телефон.
На брифинге перед сменой нажал на кнопку, синхронизировался — и вперёд к работе. Закончил ремонт, вышел в безопасное место, подгрузил данные, нажал на кнопку — отчёт ушёл в систему. Появились новые задачи — можно идти выполнять.
Правда, мог быть конфликт данных. Иногда бригады работают офлайн и могут синхронизировать результаты в разное время. Например, один ремонтник выполнил задачу раньше, но данные выгрузил позже второго. Задачу решили так: помимо времени назначения и выполнения операции добавили время создания. Для этого создали дополнительные тайм-стемпы и БД для них. Система на телефоне проверяет временную дельту: загрузил я, например, данные до 12:00 — повторно их не трогаем, забираем только те изменения, что были после полудня. То есть при синхронизации я отправляю изменения, обновляю дельты, чищу локальную БД, чтобы не копилось лишнее, и загружаю с бэка актуальную информацию.
Решив проблему работы в офлайне, мы не остановились и… добавили немного онлайна.
Для некоторых процессов важна оперативность, так что мы сделали систему пуш-уведомлений для экстренных вещей. Экстренное — это не что-то страшное, а просто ситуации, когда нужно переназначить задание или добавить новое. Например, бригада пошла работать, а тут поступила заявка на что-то рядом. Мастер раз-раз — и отправил пуш: «Посмотрите, обновите задания и поправьте, раз уж вы всё равно рядом».
Пуш всегда найдёт получателя: если в данный момент он не дошёл, то появится в следующий раз. Мы проверяем у себя каждые пять минут: это время настраиваемо. Рассылка пока общая по цеху, но при необходимости можно сделать раздельную по командам. Для пуш-уведомлений обычно используют стандартные платформы, например, Google Firebase, но мы решили сделать свою собственную систему, полностью независимую от сторонних сервисов.
Шаг второй: делаем жизнь пользователей проще
Мы сделали интерфейс максимально удобным для работы в «боевых условиях»: всё нужное — под рукой, доступ — быстрый и простой, не нужно тратить времени на поиск в меню и подменю. В общем, работать удобно даже в каске, очках и с берушами.
Создали три активные круговые диаграммы, которые обновляются в процессе работы. На них отображаются статусы работ и их выполнение. Это большие индикаторы на половину экрана. Чтобы было легче ориентироваться по приоритетам, всё отсортировано, можно вывести список задач.
Сделали дерево оборудования, так как в структуре цеха могут быть повторяющиеся агрегаты. Оборудование разделено по иерархии: начиная с самых высоких уровней можно «проваливаться» ниже, чтобы увидеть детали.
Когда несколько рабочих выполняют одну задачу, это выглядит как дополнительный экран, на котором каждый выбирает свою долю работы из каталога.
Отрисовку приложения делали не на XML, а в Compose, потому что он проще и быстрее масштабируется, кода требуется меньше, а навигация по функциям гораздо удобнее. Да и переход на него в любом случае был бы неизбежен. В общем, в будущем поддерживать приложение будет легче.
Кое-что из пользовательских потребностей мы смогли увидеть, только побывав на производстве.
Например, сценарии работы с NFC.
На всём оборудовании мы разместили NFC-метки, на которых записан номер в мастер-системе. Для рабочих это очень удобно: прислонив устройство, можно сразу перейти к нужной операции, а не искать её в списке.
Точнее, это должно было быть удобно, но появились дополнительные факторы.
До разработки приложения я не бывал на производстве, поэтому для меня отсканировать NFC — это просто «приложил — и готово».
Но это устроено не так.
Мы запросили метки и протестировали их у себя. Потом съездили с коллегой на производство, посмотрели, как это работает в реальности, и быстро всё исправили.
При проработке деталей стало ясно: на разных этапах бизнес-процесса требуется разное. Например, можно приложить метку, но выполнить не ту операцию. Решили добавить промежуточный экран: что хочет сделать пользователь, работает ли метка. Метка может быть неисправной. Если она не считывается, то проверяем в базе, есть ли такая в системе. Если нет — выводим экран для создания сообщения о неисправной метке и её замене.
С NFC, кстати, есть одна хитрость.
Обычно у RFID-меток используют только тэг, записывая в него нужную информацию. Но у них есть ещё и уникальный ID, который присваивается при производстве. Мы привязываем каждый агрегат в базе данных к этому айдишнику, и благодаря этому нам не нужно прописывать его номер в тэге, в который мы записываем информацию для других функций.
Ещё мы сделали самописную систему логирования, которая фиксирует как ошибки (например, «Задания не доходят»), так и системные события. Можно свериться, сколько данных отправлено и сколько дошло. Не хэш-сумма, но принцип тот же. Для первой линии поддержки добавили дашборды, которые помогают сразу увидеть, что произошло, и локализовать проблему.
Шаг третий: думаем о безопасности
На заводе действуют десятки требований по информационной безопасности, и нам было нужно их соблюсти.
Изначально приложение делалось для корпоративных терминалов сбора данных, на личные телефоны сотрудников его не ставят (хотя в теории это возможно). У мастер-системы и бэкенда нет выходов наружу: они полностью изолированы. Приложение подключается только к заводскому wi-fi или к корпоративной сети pLTE НЛМК.
Одним устройством могут пользоваться несколько ремонтников. Каждый может войти под своей учёткой, и между ними можно переключаться. Для удобства и быстроты в приложении есть экран с аватаркой, именем и фамилией.
Мы разделили все данные на маленькие куски и загружаем только нужную информацию. Когда человек заходит в систему, он видит только свои задачи и операции, а справочные данные об оборудовании, операциях и неисправностях хранятся в общем доступе. Это решает проблему дублирования.
Шаг четвёртый: а что дальше?
В «Техническом обслуживании и ремонте» есть базовая десктопная система. В мобильном виде — то же самое, только фронт другой. Функционала в мобильном виде меньше. Сейчас делаем перемещение оборудования и назначение в ремонт. Разница всё меньше и меньше. Для каких-то редких операций мастер-система, наверное, останется, но всё основное делается уже с телефона.
Это общий тренд: всё переходит в мобилку. С ноутбуком в цех не пойдёшь: он будет только мешать. Там нужны свободные руки и инструмент, так что телефон — оптимальный вариант: всё на ладони, всё на виду.
Телефон — это рабочий инструмент и без него уже никуда. Тем более что самые востребованные в цеху фичи уже перенесли: задания переназначаем, операции выполняем, сообщения создаём. Конечно, можно распечатать задание на случай, если система не работает, но с телефоном удобнее.
В приложении всё проще: интерфейсы адаптируем под вертикальный экран, добавляем прокрутку — вниз или вбок, где нужно. Например, на экране можно одновременно видеть диаграммы и списки. Горизонтальный скролл даёт переключаться между диаграммами: прогресс по операциям, сообщениям, ревизиям (это обслуживание с остановкой оборудования). Всё удобно и наглядно, интерфейс гибкий и интуитивный.
Нашей целью было положить весь функционал в одно устройство и в карман. И с этим мы успешно справились.