Сейчас рынок складской роботизации во многом строится на китайских роботах и готовых аппаратных решениях. И в этом нет ничего плохого: у китайских производителей сильная инженерная база, большой выбор техники и понятная экономика.
Но у такого подхода есть важная особенность, о которой часто вспоминают уже после покупки. За последние несколько лет мы не раз сталкивались с ситуацией, когда заказчик в попытке сэкономить фактически приобретает дорогой металлолом.
Логика на старте понятная:
«А зачем платить интегратору? Мы сами найдем производителя, сами съездим в Китай, сами привезем робота. Железо то же самое, значит, сэкономим».
На бумаге экономика действительно выглядит привлекательно. Есть робот, его грузоподъемность, батарея, навигация, цена и сроки поставки. Кажется, что основная ценность заключена именно в железе.
Робот сам по себе не является готовым складским процессом
После поставки появляются вопросы, которые обычно не были заложены в расчет этой экономии: кто будет настраивать карту, адаптировать сценарии под конкретный склад, разбираться с RMS, связывать робота с WMS, обучать персонал, общаться с вендором при ошибках, открывать логи и понимать, это проблема железа, софта, маршрута или эксплуатации.
И самое неприятное — кто будет отвечать, когда робот встанет.
На практике остановка робота редко означает одну очевидную причину. Это может быть потеря локализации, ошибка лидара или камеры, недоступность зарядной станции, сбой Wi-Fi, конфликт маршрутов, неверный статус задания в RMS, ошибка связи с WMS или механическая проблема привода, батареи, подъемного механизма.
Пока идет внедрение, ситуация еще выглядит управляемой: есть проектная команда, есть внимание к объекту, есть коммуникация с производителем. Но после запуска робот переходит в эксплуатацию. Он уже встроен в процесс, на него завязаны маршруты, смены, перемещение груза, ожидания по производительности.
И если в этот момент возникает серьезная поломка, это уже реальная остановка части процесса. Для владельца это деньги, а это критично для бизнеса.
Именно с такими запросами к нам сейчас все чаще приходят компании:
«Мы покупали робота не у вас. Он встал. Поддержки нет. Производитель далеко. На объекте никто не понимает, что с ним делать. Вы можете помочь?»
Для нас это уже не теоретический вопрос. Мы как интегратор полного цикла видим, что рынок подходит к этапу первых серьезных сервисных проблем после внедрения роботизированных решений.
Отдельный слой здесь — RMS
Если упростить, RMS — это система управления роботами: задачи, статусы, маршруты, ошибки, заряд, события, состояние парка. Она переводит робота из состояния отдельной машины в состояние управляемого элемента складского процесса.
Но RMS сама по себе тоже не решает проблему. Ее нужно правильно настроить, связать с реальными сценариями склада и, если требуется, интегрировать с WMS. Если заранее не описать, какие статусы робот возвращает, как обрабатываются исключения, кто видит ошибки и кто принимает решение о вмешательстве, RMS быстро превращается в панель, на которой видно, что что-то пошло не так, но непонятно, что с этим делать.
Сервисная модель начинается не с выезда инженера, а с доступа к данным. Если робот остановился, важно видеть не только сам факт ошибки, но и контекст: какое задание выполнялось, где робот находился, какой маршрут строил, был ли он связан с RMS, получал ли команды от WMS, что происходило с батареей, датчиками безопасности, приводами, сетью и локализацией.
Инженер видит, что робот стоит, но не понимает, это механическая неисправность, потеря карты, ошибка задания, проблема Wi-Fi, конфликт в RMS или некорректный статус со стороны WMS.
Например, сообщение «robot offline» само по себе почти ничего не говорит. Робот мог потерять Wi-Fi, зависнуть на уровне бортового ПО, уйти в защитный режим после срабатывания датчика безопасности или продолжать работать локально, но потерять связь с диспетчерской системой. Для склада результат один — робот недоступен. Для сервиса это четыре разных сценария восстановления.
Для анализа может потребоваться:
-
журнал событий робота;
-
коды ошибок и предупреждений;
-
последнее выполняемое задание;
-
точка маршрута, на которой произошла остановка;
-
статус батареи и зарядной станции;
-
состояние лидаров, камер, бамперов, кнопок аварийной остановки;
-
телеметрия приводов и контроллеров;
-
качество связи с RMS;
-
сетевые события: потери соединения, задержки, переподключения;
-
история команд от RMS;
-
история обмена с WMS;
-
логи ручного вмешательства оператора;
-
версия прошивки, ПО робота и RMS.
На наш взгляд, именно связка «железо + RMS + сервисная модель» будет дальше определять качество роботизированных проектов.
Робот может быть хорошим. RMS может быть функциональной. Первый запуск может пройти успешно. В видео мы рассказываем почему сервисная модель неотъемлемая часть интеграции роботизированных решений.
Но если после этого на объекте нет людей, которые умеют читать поведение системы, отличать ошибку сценария от ошибки оборудования, доставать логи, общаться с вендором на техническом языке и быстро возвращать процесс в работу, заказчик остается не с автоматизацией, а с зависимостью и проблемами.
Мы к этому шли несколько лет. Сервисная экспертиза в роботизации не появляется после одной поставки. Она накапливается через реальные объекты, реальные отказы, нестандартные ошибки, долгие пусконаладки, коммуникацию с производителями, адаптацию документации, обучение инженеров, работу с запчастями и понимание того, как техника ведет себя не в демо, а в эксплуатации.
Сейчас становится понятно, зачем это было нужно.
Когда робот встает на объекте, заказчику не нужен общий разговор про будущее складской автоматизации. Ему нужно понять четыре вещи:
-
что произошло;
-
можно ли восстановить работу без производителя;
-
что делать смене прямо сейчас;
-
как не повторить эту ситуацию снова.
Хорошая сервисная модель должна описывать не только ремонт, но и временное восстановление процесса: перевод задания на другого робота, ручной обход маршрута, исключение проблемной зоны из карты, возврат робота на базу, безопасный сброс ошибки, повторную синхронизацию статуса между RMS и WMS.
Нужно задавать вполне конкретные вопросы:
-
кто будет участвовать в пусконаладке;
-
кто понимает RMS;
-
кто имеет доступ к логам и ошибкам;
-
кто сможет разговаривать с вендором на техническом языке;
-
какие сценарии отказа уже описаны;
-
что делает склад, если робот недоступен несколько часов;
-
кто отвечает за возврат техники в процесс после сбоя.
Купить робота становится проще.
Сложнее — построить вокруг него эксплуатационную модель, в которой робот не просто запускается, а продолжает работать после первых серьезных проблем. И, возможно, именно по этому признаку рынок дальше будет делиться на два подхода.
Первый — «мы поставили железо». Второй — «мы отвечаем за то, чтобы роботизированное решение жило в процессе».
Для склада разница между ними становится видна не в день запуска, а в день первой серьезной поломки.
ссылка на оригинал статьи https://habr.com/ru/articles/1029438/