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

Привет, Habr! На связи Александр Тамразов и Дмитрий Кривенко, разработчики из Аxenix.

В этой статье поделимся кейсом, как мы создали и разработали универсальную систему автоматизации производства для одного из клиентов и помогли улучшить бизнес-процессы. Расскажем про требования, бизнес-метрики и пройдемся по технической части: архитектуре, стеку, деталям про backend + frontend + IoT, подходам к разработке. Закончим разговором мониторингом и тем, как масштабировать такое решение.

Проблемы процессов клиента и человеческий фактор

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

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

Мы провели исследование и сформулировали бизнес-задачу: отслеживать перемещение заказов, смену их статусов и дать сотрудникам доступ к круглосуточному видеопотоку с этой информацией.

Внутри сервиса: логика, архитектура, бэкенд и фронтенд

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

Вот что мы получили на уровне проекта:

1. Скорость и доступ. Получился быстрый круглосуточный онлайн-сервис.

2. История заказов. Сейчас информация о заказах из одного цеха в другой собирается за один год.

3. Удобный интерфейс. Сотрудникам понятно, как работать с сервисом и как быстро получить информацию по любому заказу.

4. Уведомления. Информация о заказах приходит автоматически. Об изменениях статуса или местоположения заказа сообщают push-уведомления.

Дополнительно появилась возможность собирать аналитику движения транспорта в дашборды.

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

Отслеживаем местоположение заказа с помощью RFID

В начале работы мы исследовали весь путь, по которому едет транспорт клиента из одного цеха в другой. Чтобы понять всю схему перемещения, решили детектировать и считывать местоположение. Для этого на каждый вагон установили RFID-метки.

RFID (Radio Frequency Identification или радиочастотная идентификация) — это способ автоматической идентификации объектов, который позволяет использовать радиочастотные сигналы для считывания и записи информации с меток, прикреплённых к объектам. Метки содержат уникальный идентификатор, который определяет вагоны на общей схеме.

Как только вагон проходит мимо RFID-антенны, его положение считывается, а сотрудники цеха с помощью камер видят, что происходит с заказом в дороге.

Бэкенд и архитектура

Весь бэкенд написан на Java и Spring Boot. Для хранения данных использовали PostgreSQL, для кэширования — Redis.

Система состоит из нескольких микросервисов:

• RFID-коннектор. Устанавливает связь с RFID-считывателями через сокет и передаёт полученные данные в Kafka для обработки.

• Микросервис агрегирования данных. Получает информацию не только от RFID-коннектора, но и из других источников, таких как сервис слежения, сервис заказа, MDM-таблицы и другие. Этот микросервис агрегирует и объединяет все данные перед отправкой в Kafka.

• Сервис аналитики данных. Получает данные из Kafka и анализирует их для вычисления различных эффектов. Таких, как подсчёт среднего времени прохождения отрезков пути, простоя перед цехами, начала и окончания разгрузки; анализ RFID меток на предмет их ошибок и подсчёт количества прибывших и разгруженных вагонов за сутки; подсчёт вагонов, которые в данный момент находятся в цехах переработки, в цехах хранения материалов, в ремонте. Также он предоставляет данные для микросервиса трекинга.

• Сервис трекинга. Также получает данные из Kafka и использует их для формирования составов из вагонов, которые видит пользователь.

• BFF (back for front). Служит как связующее звено между аналитическим и трекинговым микросервисами, собирая данные для удобного отображения на фронтенде.

• Сервис заказа. Отвечает за формирование заказов и организацию доставки груза между цехами.

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

Проблема 1: сменился поставщик устройств RFID

Ранее у заказчика уже был опыт работы с RFID-технологией, но в процессе работы над сервисом сменился поставщик устройств, и страной производства считывателей стал Китай. Сами по себе китайские устройства неплохие, но были сложности с документацией.

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

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

Проблема 2: клиент взял на себя часть разработки

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

Заказчик хотел реализовать систему слежения за статусами самостоятельно. Новые статусы должны были отображаться на общей схеме, а менять их должны были работники цеха. Мы согласились, но в нужный момент система слежения не была готова — не хватало двух-трёх месяцев. Пришлось ждать.

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

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

Проблема 3: сила привычки у сотрудников и откаты к старым методам работы

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

Всё казалось отлично. Заказы создавались, работники были довольны, состав двигался, и заказчик был в восторге. Но в игру вступил человеческий фактор. Работники допускали ошибки, указывали неверные номера вагонов или выбирали вагоны, которые не должны участвовать в перевозке. Ещё иногда работники обходили систему и использовали старый способ заказа — по телефону.

Из-за проблем как с RFID, так и с сервисом заказа, схема перестала корректно работать. Данным не всегда можно было верить. Так мы решили разработать алгоритм для анализа и автоматического включения вагонов в состав.

Алгоритм реализовали следующим образом.

Шаг 1: анализируем историю времени сканирования вагонов на конкретных считывателях.

Шаг 2: сравниваем временные отметки сканирования вагонов и ищем случаи, когда один и тот же вагон сканируется на одном и том же считывателе с разницей во времени, которая не превышает определённого значения (дельты).

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

Клиентская часть

Фронтенд-часть сервиса включает реестр заказов с карточками для каждого заказа. Реестр предоставляет обзор всех текущих заказов, а карточки содержат детальную информацию по каждому заказу.

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

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

Части мнемосхемы заказов

Веб-приложение написано на React и TypeScript. Все компоненты, включая мнемосхемы, простые: их легко заменить, настроить или расширить. Мнемосхема может взаимодействовать с оборудованием как через бэкэнд, так и через прокси-сервер для обеспечения безопасного соединения. Есть механизмы health-check и обработки ошибок, которые обеспечивают круглосуточную доступность приложения для заказчика и сотрудников. 

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

Обмен данными с бэкендом осуществляется с использованием связки REST+WebSocket. Последний используется как сервис согласования, который оповещает о событиях, происходящих на бэкенде, например, когда транспортное средство проходит метку RFID. Это позволяет мгновенно обновлять данные на фронтенде. А обновления данных через REST выполняются с помощью BFF-сервиса. BFF (Back for Frontend) является удобным инструментом, который позволяет легко модифицировать данные и снижает нагрузку на фронтенд, избегая лишней обработки данных на стороне клиента.

Давайте более подробно рассмотрим какие проблемы и преимущества возникали в процессе разработки:

1. Оптимизация отрисовки на React. Здесь применялись внутренние методы оптимизации. Они позволяют перерисовывать только те части мнемосхемы, которые изменились. Например, если транспортное средство переместилось, мы обновляли только его положение, не перерисовывая всю мнемосхему. 

2. Использование WebSocket. Нам хотелось обеспечить реальное время в обновлениях, однако из-за особенностей оборудования и транспорта такую задачу сложно было реализовать. Вместо этого, единый сервис оповещений уведомляет, что транспорт изменил местоположение. Это отображается на мнемосхеме. Но иногда количество оповещений избыточно из-за RFID-меток, присутствующих на каждом транспортном средстве. Для решения мы использовали браузерный кэш и оптимизацию сетевых запросов.

3. Легковесная отрисовка с использованием SVG. Мы реализовали легковесную отрисовку, что обеспечило быструю загрузку мнемосхемы при первом посещении веб-страницы.

4. Использование BFF-сервиса. Back for Frontend-сервис снижал нагрузку на фронтенд, облегчая агрегацию данных и упрощая внесение изменений в контракты и структуру данных.

RFID-оборудование и CCTV-камеры

В процессе решения задачи мы столкнулись с двумя проблемами: избыточной перерисовкой и получением видео с камер на мнемосхеме. 

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

Что касается получения видео с камер, была задача клиента — детектировать транспорт с помощью RFID. Мы успешно считывали местоположение, хотя и не в режиме реального времени. Однако с CCTV-камерами возникла проблема безопасности. Клиенту была важна максимальная безопасность передачи видеопотока. Мы создали специальный прокси-сервер, который шифрует видео и аудиопоток с протокола ws на wss (веб-сокет протокол с использованием шифрования). Теперь сотрудники могут получать видеопоток безопасно, удовлетворяя потребности клиента в безопасности данных.

Аналитика сервиса через визуализацию метрик

В процессе разработки у нас возникла потребность в сборе аналитики с фронтенда, включая информацию о числе посетителей и их взаимодействии с мнемосхемой. Для этой цели решили использовать сервис Matomo. Это opensource-библиотека для сбора аналитических данных, похожее на Google Analytics. 

Однако, чтобы удовлетворить требования клиента, нам нужно было интегрировать аналитику из МАТОМО в Grafana. Здесь возникла проблема, так как не существовало подходящего плагина, который мог бы переносить данные. Поэтому мы использовали самописные инструменты, используя API МАТОМО и библиотеку Json-datasource для Grafana. Так получилось и перенести данные, и отобразить всё на дашбордах.

Результаты работы на фронте

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

Мнемосхема сама по себе является уникальной для каждого предприятия и его географии, но её легко масштабировать, добавлять новые объекты, менять SVG-компоненты или пересобирать по необходимости.

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

Итоги

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

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

У клиента перестал пропадать транспорт: RFID-мониторинг сделал маршрут между цехами прозрачнее и помог выявить место, где происходят задержки. А сотрудники двух цехов получили систему, в которой отображается актуальный статус каждого заказа. Им стало удобно смотреть, что происходит с заказами, и оптимизировать своё время, в зависимости от этой информации.

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

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

• увеличить скорость доставки;

• снизить время простоя составов перед цехами;

• уменьшить финансовые потери заказчика.

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

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

На сегодняшний день в нашей системе фиксируется более 200 вагонов в сутки. Благодаря автоматизации, клиенту удалось сократить время простоя вагонов и груза на 20%. Раньше вагоны могли стоять неделю, пока кто-то из сотрудников другого цеха не приедет проверить, где они. Также выросло количество доставок в сутки с 60-70 до 120. А с помощью аналитики, клиент увидел в процессе критичные проблемы и смог увеличить скорость разгрузки сырья на треть, время сократилось с 60 до 40 минут.