Оптимизируем логистику для угледобывающей компании

Проблема — старое решение работает, но нет нужных функций

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

Работы проходят постоянно и в разных местах, а значит дороги на разрезе меняются каждый день. По ним перемещаются специальные самосвалы, например, «БелАЗы». Они крупнее обычных самосвалов и могут перевозить в 3–10 раз больше груза, но и расход топлива гораздо выше. Путь такого грузовика должен быть максимально эффективным: без простоев и пробок.

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

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

Решение — новый сервис на основе open-source библиотек

За 3 месяца мы разработали для Восточной горнорудной компании MVP нового сервиса для отрисовки дорог на угольном разрезе.

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

• редактирование карты (отрисовка новых дорог и площадок),
• управление списком дорог и полигонов
• версионность,
• разграничение доступа.

Фронтенд

В качестве картографического решения мы нашли свободно распространяемую библиотеку, которая была бы похожа на то, что использовали операторы ранее. К ней добавили JS-библиотекудля редактирования элементов. Теперь интерфейс похож на работу в графическом редакторе: отдельные слои для разных видов сущностей, разные режимы редактирования дорог и площадок. Данные с машин поступают в виде серии точек, которые и образуют путь конкретной машины. Таких точек на карте может быть 10 000 и более.

Бэкенд

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

Одной из сложных задач стала обработка данных. Сервер должен не только принимать телеметрию и отправлять ее на фронтенд, но и валидировать изменения, пришедшие с фронтенда. Например, оператор нарисовал новую дорогу, бэкенд должен сохранить ее как новую версию карты. Мы создали API, которое определяло список изменений на карте дорог и полигонов и выполняло необходимые действия для update/create/delete. Для проверки изменений добавили систему правил взаимодействия сущностей.

RestAPI создано с помощью django-rest — это существенно ускоряет разработку и упрощает поддержку, так как этот инструмент многое умеет из «коробки».

Для документирования API использовали Swagger. Его преимущество в том, что отчасти он автоматизирует этот процесс: когда на бекенде появляется эндпоинт, информация о нем сразу появляется в Swagger. Это удобно для связи с фронтендом и отладки, так как в одном месте полностью увидеть информацию о том, какие «ручки» есть на бекенде.

DevOps

Система изначально сдавалась под кубер и полноценный CI/CD.

Команда клиента использует Kubernetes и полноценный CI/CD процесс, поэтому на стадии MVP мы подготовили стандартный набор, ориентированный на скоростное развертывание. На его основе можно написать отдельные пайплайны под новые нужды.

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

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

Результат и планы

Сервис позволяет ежедневно поддерживать актуальное состояние отвалов и дорог.

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

Для того, чтобы данные хранились в консистентном виде, сервис проверяет новые или измененные объекты по внутренним правилам и выводит ошибку, если что-то пошло не так.

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

С точки зрения администрирования, мы разграничили доступы к разным фичам приложения на роль редактора и пользователя «read-only». Вместе с версионированием карт это большая страховка от случайных ошибок и изменений.

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

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