- BrainTools - https://www.braintools.ru -
У любой сложной технической системы есть граница, на которой модель больше не совпадает с реальностью. Если вы видели систему со всеми зелёными метриками, но интуиция [1] подсказывала, что дежурство будет тяжёлым, вы знаете это состояние. В распределительных центрах эту границу видят не в логах и дашбордах, а на полу склада. Когда алгоритм уже всё просчитал, а физический мир внёс свои правки.
Эта статья не про роботов как технологию и не про автоматизацию как цель. Она про роль, которая появляется, когда автоматизация становится массовой. Про человека, который стоит между WMS, роботами и реальным складом. И про то, почему без этой роли, даже если формально всё работает, автоматизация со временем деградирует.
Распределительные центры Х5 — это большие логистические хабы, которые снабжают десятки тысяч магазинов по всей стране. По устройству он ближе всего к дата-центру. Только вместо серверов здесь стеллажи с палетами, а вместо сетевых кабелей маршруты перемещения товара. Это десятки тысяч квадратных метров пространства, разбитые на зоны с разными температурными режимами и правилами доступа. Поток товаров проходит от приёмки к отгрузке так же непрерывно, как трафик между сервисами в облаке.
Вдоль стеллажей постоянно движутся роботы и люди в касках. Если смотреть инженерно, это физический слой системы. То, что в дата-центре называют железом, стойками и кабельными трассами. По полу проходят полосы навигации и метки, по которым ориентируются роботы. Это аналог сетевой топологии и таблиц маршрутизации. Ошибка [2] в метке или её износ влияют на поведение [3] робота так же, как ошибка в конфигурации сети влияет на поведение [4] сервиса.
Как и в дата-центре, на складе нет одного типа вычислительных узлов. Нагрузка распределена между разными классами машин со своими ролями и ограничениями.
В одном секторе работают автономные мобильные роботы (AMR) – невысокие платформы с датчиками по периметру. Они почти не привлекают внимания [5] и не выглядят как тяжёлая техника. Но именно они закрывают большую часть рутинных перемещений внутри зоны. Если проводить аналогию, это фоновые сервисы, которые постоянно крутятся и обеспечивают базовую пропускную способность системы.
Чуть дальше видны автономные вилочные погрузчики (FMR). Они получают задания из системы управления, строят маршрут, поднимают грузы и везут их в нужные точки. Эти узлы работают с большими объёмами товаров и чувствительны к ошибкам в навигации и окружению.
Кроме них на складе есть и другая автоматизированная техника. Роботы для уборки, сканеры инвентаризации, специализированные модули под отдельные операции. У каждого типа свои правила движения, свои датчики и сценарии отказов. Как и в сложной инфраструктуре, все эти компоненты работают в одном пространстве и неизбежно влияют друг на друга.
Как в серверной, где басовито работают вентиляторы и диски, на большом складе постоянно слышен механический фон работы системы. Пока он ровный, всё в порядке. Его быстро перестаёшь замечать, но любое изменение громкости или темпа даёт понять, что в системе что-то пошло не так.
Типовой сбой не выглядит как авария. Нет сирен и красных экранов. Просто в какой-то момент один из роботов останавливается не там, где должен. Он получил задачу, построил маршрут, доехал почти до конца и застыл. Например, не смог проехать в ворота между зонами. Ведь у него в настройках на эту операцию всего три попытки. Формально он выполнил всё, что от него требовалось, но на самом деле перекрыл проезд.
Поэтому за ним остановился следующий робот. Потом ещё один. И через несколько минут в узком месте собралась очередь из машин, которые по расписанию должны были давно разъехаться по своим задачам. При этом в интерфейсе системы всё выглядит спокойно. Один робот в статусе ожидания оператора, остальные числятся активными. Но на полу склада уже видно, что поток начал схлопываться.
Причина затора может быть любой. Медленно открывшиеся ворота между зонами. Плёнка, торчащая с соседней палеты и попавшая в поле лидара. Смещённая метка навигации. Для алгоритма это непреодолимое препятствие, а для склада — настоящая проблема. Автоматический сценарий на этом месте заканчивается. Робот не поедет дальше сам. А система не понимает, что именно пошло не так, поэтому будет ждать. И чем дольше она ждёт, тем больше машин простаивает и сильнее сдвигаются сроки погрузки и разгрузки.
В этот момент на сцене появляется погонщик роботов. Он подходит к остановившейся машине и смотрит не на логи, а на то, что не может увидеть система. Человек сразу понимает, что мешает проезду. Переводит робота в ручной режим. Отводит его в безопасную зону или вручную завершает задачу. Маршрут освобождается, и движение постепенно возвращается в рабочий ритм.
Функционал погонщика зависит от типа робота и бизнес-процесса, в котором он используется, но сакральный смысл обязанностей погонщика — всегда помогать роботу, когда не хватает системных алгоритмов. Вроде бы всё слишком просто, но за этими действиями скрыто несколько глубинных слоёв.
Сердце склада — Warehouse Management System (WMS). Эта система знает, какие товары, где и когда должны находиться. Она управляет приёмкой, хранением, комплектацией и отгрузкой. Все складские операции начинаются именно в ней. WMS решает, какую бизнес-задачу нужно выполнить и кому её отдать — человеку или автоматике. WMS ничего не знает о количестве роботов, состоянии их заряда, доступности, не учитывает возможные пробки и столкновения.
На каждом роботизированном распределительном центре есть выделенные участки, которые обслуживаются только роботами. Для них WMS формирует общую задачу перемещения, в которой нет конкретного робота, а описано только, что нужно сделать: что взять, откуда и куда переместить.
До робота задача не доходит напрямую. Между WMS и машинами есть промежуточный слой управления. В зависимости от реализации это может быть Warehouse Control System (WCS) – система управления складской автоматикой, или Robotics Management System (RMS). Именно эта система и занимается роботами на низком уровне.
WCS или RMS получает задачу от WMS, смотрит на текущее состояние зоны и выбирает ближайшего свободного робота. После этого строит для него маршрут из точки «А» в точку «Б» с учётом карты склада, ограничений зон, занятости проходов и текущих ошибок. Для RMS это конкретный сценарий движения конкретной машины, а для WMS всё это одна задача. Он собирает только информацию о статусах выполнения задач, причины ошибок или отмены задач, в том числе остальные данные о роботах WMS не интересуют.

Погонщик работает именно на этом уровне. Его основной интерфейс — система управления роботами. На экране он видит схему зоны, маршруты, состояние каждого робота и статус их задач. Если робот останавливается или переходит в режим ожидания, это сразу видно в RMS. Но интерфейс не всегда объясняет причину остановки.
Работа погонщика начинается не с ошибки, а с отклонения от нормального поведения. Пока робот движется по маршруту, его состояние меняется предсказуемо. Сигналом считается момент, когда движение прекращается не там, где ожидалось: робот стоит дольше обычного, переходит в статус ожидания оператора или не освобождает маршрут по расписанию.
Например, раньше, когда робот считал ячейки занятыми, он запрашивал новое место назначения у WMS, и ситуация могла повторяться до двадцати раз, пока погонщик не замечал странное поведение робота. Поэтому появился запрет на перезапрос ячейки не более трёх раз. После трёх неудачных попыток размещения робот останавливается и просит помощи у погонщика. Система фиксирует факт остановки, но не знает причины. В этот момент управление задачей фактически переходит от неё к человеку.
Важно, что погонщик не управляет логикой [6] распределения задач и не меняет алгоритмы WMS или RMS. Его роль – в закрытии разрыва между моделью, в которой живёт система, и физической реальностью склада, чтобы восстановить поток.
После вмешательства система получает результат. Если задача завершена вручную, маршрут считается освобождённым, и остальные роботы продолжают работу. Если задача отменена, в системе фиксируется причина отмены.
|
Сигнал в системе или на складе |
Что это означает |
Решение погонщика |
Системное последствие |
|
Робот долго стоит на маршруте |
Робот не смог продолжить движение |
Проверка ситуации в зоне, осмотр окружения |
Принятие решения о ручном вмешательстве |
|
Робот в статусе ожидания оператора |
Автоматика признала невозможность продолжения |
Перевод робота в ручной режим |
Автоматический сценарий остановлен |
|
Робот остановился в узком месте |
Потенциальная блокировка потока |
Отвод робота в безопасную зону |
Освобождение маршрута |
|
За одним роботом скапливаются другие |
Начало затора |
Приоритетное вмешательство |
Восстановление движения в зоне |
|
Несколько неудачных попыток выполнения задачи |
Задача не может быть выполнена автоматически |
Отмена задачи или ручное завершение |
Фиксация ошибки в системе |
|
Робот не может поставить палету |
Физическое препятствие или ошибка окружения |
Ручное размещение палеты или вызов помощи |
Завершение операции |
|
Робот потерял ориентацию |
Проблемы с навигационными метками |
Коррекция ситуации на месте |
Возврат робота в работу |
|
Робот не уехал на зарядку |
Ошибка маршрута или препятствие |
Ручной отвод на зарядную станцию |
Восстановление доступности робота |
|
Отмена задачи погонщиком |
Задача не имеет корректного автоматического решения |
Указание причины отмены |
Сбор статистики по причинам сбоев |
Это появилось не сразу. Раньше отмена задачи означала просто отмену, без дополнительного контекста. Для IT это выглядело как шум. Что-то пошло не так, но почему именно и где именно, было непонятно. Физический мир не умел разговаривать с системами. Но со временем стало ясно, что без обратной связи дальше развивать автоматизацию не получится. Роботы продолжат останавливаться в одних и тех же местах, а люди – решать одни и те же проблемы руками.
Тогда и появилась фиксация причин. Погонщик отменял задачу или завершал её вручную, он указывал причину из ограниченного набора, сформированного из реальных кейсов на складе. Так становилось видно, какие ситуации повторяются чаще всего и где модель регулярно расходится с реальностью.
Именно на этом стыке между сигналом, решением и последствием роль погонщика перестаёт быть вспомогательной и становится частью архитектуры склада.

Для IT это точка входа в изменения. Если проблема системная, её забирают в работу. Меняют логику распределения задач. Ограничивают количество автоматических попыток. Корректируют маршруты или правила выбора ячеек. Если проблема не в коде, а в инфраструктуре, дорабатывают разметку, ворота или зоны движения. Команда разработки Nexus WMS всегда находится в активном контакте с командой запуска проекта, и на основе обратной связи прорабатывает варианты улучшений и оптимизации алгоритмов системы.
Для бизнеса эта статистика показывает расхождение между процессом, заложенным в систему, и тем, как он реально выполняется людьми. Например, в одном из кейсов зона аномалий начала заполняться сильнее, чем предполагалось в концепции. Формально система работала корректно. Физически процесс был нарушен из-за ручных изменений параметров заказов.
Погонщик разрывает этот цикл. Он закрывает инцидент здесь и сейчас, а заодно оставляет след, по которому систему можно доработать.
Системы управления роботами будут становиться сложнее. Появится больше автоматических сценариев, больше алертинга, улучшится распознавание препятствий. Часть типовых ситуаций уйдёт на уровень алгоритмов и перестанет требовать ручного вмешательства, но физический склад не станет детерминированной средой. Поменяются процессы, устареет инфраструктура, появятся новые зоны и типы роботов, но исключения никуда не исчезнут, они просто изменят форму. С увеличением уровня автоматизации будет повышаться сложность используемых алгоритмов в системе, потому что WMS должна обеспечивать точность планирования задач. Робот ещё не может «подумать», как лучше выполнить задачу в условиях неопределённости. А человек способен самостоятельно проанализировать происходящее без системы. К примеру, робот сейчас не может работать с ячейками, в которых более одной палеты, а человек может. Поэтому роль «погонщика» не пропадёт. Она сместится от ручных действий к контролю и диагностике, но граница, на которой модель встречается с реальностью, останется за человеком.
Роботы в распределительных центрах X5 уже давно не редкость. Компания тестирует и внедряет AMR и FMR в ходе пилотных проектов по автоматизации операций. Но технологический прогресс не отменяет физического мира. Он сложнее любого кода. И там, где автоматического режима оказывается недостаточно, на помощь приходит погонщик роботов. Он тот, кто закрывает петли, которые не учтены в алгоритмах. Возможно, его действия не так эффектны, но они поддерживают ритм склада и позволяют системе работать без остановок.
Автор: Rombneromb
Источник [7]
Сайт-источник BrainTools: https://www.braintools.ru
Путь до страницы источника: https://www.braintools.ru/article/25908
URLs in this post:
[1] интуиция: http://www.braintools.ru/article/6929
[2] Ошибка: http://www.braintools.ru/article/4192
[3] поведение: http://www.braintools.ru/article/9372
[4] поведение: http://www.braintools.ru/article/5593
[5] внимания: http://www.braintools.ru/article/7595
[6] логикой: http://www.braintools.ru/article/7640
[7] Источник: https://habr.com/ru/companies/X5Tech/articles/1001330/?utm_campaign=1001330&utm_source=habrahabr&utm_medium=rss
Нажмите здесь для печати.