Зачем роботам погонщик?

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

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

Склад как физическая распределённая система

Распределительные центры Х5 — это большие логистические хабы, которые снабжают десятки тысяч магазинов по всей стране. По устройству он ближе всего к дата-центру. Только вместо серверов здесь стеллажи с палетами, а вместо сетевых кабелей маршруты перемещения товара. Это десятки тысяч квадратных метров пространства, разбитые на зоны с разными температурными режимами и правилами доступа. Поток товаров проходит от приёмки к отгрузке так же непрерывно, как трафик между сервисами в облаке.

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

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

В одном секторе работают автономные мобильные роботы (AMR) – невысокие платформы с датчиками по периметру. Они почти не привлекают внимания и не выглядят как тяжёлая техника. Но именно они закрывают большую часть рутинных перемещений внутри зоны. Если проводить аналогию, это фоновые сервисы, которые постоянно крутятся и обеспечивают базовую пропускную способность системы.

Чуть дальше видны автономные вилочные погрузчики (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, и ситуация могла повторяться до двадцати раз, пока погонщик не замечал странное поведение робота. Поэтому появился запрет на перезапрос ячейки не более трёх раз. После трёх неудачных попыток размещения робот останавливается и просит помощи у погонщика. Система фиксирует факт остановки, но не знает причины. В этот момент управление задачей фактически переходит от неё к человеку.

Важно, что погонщик не управляет логикой распределения задач и не меняет алгоритмы WMS или RMS. Его роль – в закрытии разрыва между моделью, в которой живёт система, и физической реальностью склада, чтобы восстановить поток.

Сигнал, решение и граница ответственности

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

Это появилось не сразу. Раньше отмена задачи означала просто отмену, без дополнительного контекста. Для IT это выглядело как шум. Что-то пошло не так, но почему именно и где именно, было непонятно. Физический мир не умел разговаривать с системами. Но со временем стало ясно, что без обратной связи дальше развивать автоматизацию не получится. Роботы продолжат останавливаться в одних и тех же местах, а люди – решать одни и те же проблемы руками.

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

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

Для IT это точка входа в изменения. Если проблема системная, её забирают в работу. Меняют логику распределения задач. Ограничивают количество автоматических попыток. Корректируют маршруты или правила выбора ячеек. Если проблема не в коде, а в инфраструктуре, дорабатывают разметку, ворота или зоны движения. Команда разработки Nexus WMS всегда находится в активном контакте с командой запуска проекта, и на основе обратной связи прорабатывает варианты улучшений и оптимизации алгоритмов системы.

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

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

Почему эта роль не скоро исчезнет

Системы управления роботами будут становиться сложнее. Появится больше автоматических сценариев, больше алертинга, улучшится распознавание препятствий. Часть типовых ситуаций уйдёт на уровень алгоритмов и перестанет требовать ручного вмешательства, но физический склад не станет детерминированной средой. Поменяются процессы, устареет инфраструктура, появятся новые зоны и типы роботов, но исключения никуда не исчезнут, они просто изменят форму. С увеличением уровня автоматизации будет повышаться сложность используемых алгоритмов в системе, потому что WMS должна обеспечивать точность планирования задач. Робот ещё не может «подумать», как лучше выполнить задачу в условиях неопределённости. А человек способен самостоятельно проанализировать происходящее без системы. К примеру, робот сейчас не может работать с ячейками, в которых более одной палеты, а человек может. Поэтому роль «погонщика» не пропадёт. Она сместится от ручных действий к контролю и диагностике, но граница, на которой модель встречается с реальностью, останется за человеком.

Заключение

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