Робот редко работает сам по себе. На складе ему нужно знать, какой поддон и куда везти. В цеху он должен получить партию и сообщить, что она готова. В больнице курьерский робот должен принять заявку из учётной системы. Если связи нет, эти данные приходится вводить руками, а ошибки при ручном вводе быстро съедают пользу от автоматизации.
Эта статья объясняет, как устроена интеграция робота с системами учёта (WMS, MES, ERP, 1С), какие есть способы связи и где обычно возникают проблемы. Мы не называем сроки и цены: они зависят от модели, системы и объёма работ. Их нужно оценивать вместе с поставщиком и интегратором.
Зачем нужна интеграция
Интеграция решает две задачи: робот получает задания и отчитывается о результате. Задание приходит из учётной системы (перевезти, отобрать, отсортировать, доставить), а отчёт возвращается туда же (выполнено, ошибка, остаток, время).
Без интеграции люди сами ставят задачи через экран или программу робота, а потом вручную подтверждают результат в учёте. Для небольшого объёма это терпимо. Для склада с потоком заказов или для линии с учётом партий это узкое место: растёт число ошибок, а данные в системе отстают от реальности.
Когда можно обойтись без интеграции
Бывают случаи, когда связь с учётной системой не нужна или избыточна:
- Пилот. На пробном запуске часто достаточно ручных заданий, чтобы проверить навигацию и сценарий. Интеграцию делают после решения о покупке, но заранее проверяют, что она возможна. О пилоте читайте в статье Как внедрить робота.
- Уборочные роботы. Они работают по карте и расписанию и не обмениваются данными с учётом.
- Роботы-официанты и роботы-администраторы. Обычно их задачи ставит персонал на месте. Связь с кассовой или гостиничной системой нужна не всегда и зависит от решения.
- Единичные манипуляторы на простой операции, где программа в самом роботе не зависит от внешних данных.
Правило простое: интеграция нужна там, где задача робота определяется данными из учёта и результат должен вернуться в учёт.
Уровни: кто чем владеет
Чтобы не запутаться в ответственности, полезно разделить систему на три уровня.
- Робот. Выполняет движение или операцию, знает своё состояние (заряд, ошибки, положение).
- Система управления производителя. Для мобильных роботов это обычно диспетчер или флот-менеджер: он распределяет задания между машинами, строит маршруты, разводит роботов в проходах, отправляет на зарядку. Для манипуляторов роль похожа у контроллера или программы ячейки.
- Учётная система предприятия. WMS (управление складом), MES (управление производством), ERP или 1С. Она знает заказы, остатки, партии, адреса хранения.
Главный принцип: учётная система говорит, что нужно сделать, а флот-менеджер решает, как именно и каким роботом. Учёт не должен управлять каждым движением. Иначе любой сбой связи останавливает машины, а любое изменение в учёте ломает движение.
Типичное разделение владения:
| Что | Кто владеет |
|---|---|
| Заказы, остатки, партии, адреса | Учётная система предприятия |
| Очередь заданий роботов, маршруты, зарядка | Флот-менеджер |
| Безопасность движения, остановка | Робот и его контроллер |
| Карта помещения и зон | Флот-менеджер, согласуется с предприятием |
| Связь с лифтами, дверями, конвейерами | Интегратор вместе со службой, отвечающей за оборудование |
Запишите эту таблицу в проекте и закрепите за каждой строкой ответственного. Вопрос «кто чинит, когда не доехал» без неё превращается в спор между поставщиком робота, поставщиком WMS и ИТ-отделом.
Способы связи
Универсального способа нет. На практике встречаются четыре.
Открытый интерфейс производителя (API, SDK)
Производитель публикует описание, по которому внешняя система может создавать задания и получать статусы. Это самый чистый вариант: вы или интегратор пишете связку между учётом и флот-менеджером. Для такого API обычно используют веб-интерфейсы на основе REST. Важно, чтобы описание было полным, актуальным и закреплено за версией ПО.
Для мобильных роботов существует и отраслевой стандарт общения диспетчера с машинами: VDA 5050, интерфейс для AGV и AMR между системой управления и роботами. Он помогает смешивать технику разных производителей, но поддержка стандарта у конкретной модели каталога не подтверждена. Спрашивайте об этом поставщика письменно.
Промежуточное ПО интегратора
Интегратор ставит между учётом и флот-менеджером собственный слой (шлюз, шину, адаптер). Он преобразует форматы, ведёт журналы, повторяет отправку при сбоях. Такой вариант выбирают, когда у робота нет готового коннектора к вашей WMS или к 1С, либо когда нужно соединить несколько систем.
Плюс: ответственность за связку у одного исполнителя. Минус: появляется ещё один компонент, который нужно сопровождать и обновлять.
Обмен файлами
Самый простой и самый хрупкий способ: одна система кладёт файл с заданиями в папку, другая читает. Он годится для пилота или для редких обменов, например раз в смену. Для потока заказов в реальном времени он плох: нет подтверждения доставки, сложно отследить потерянный файл, ошибки формата обнаруживаются поздно.
Связь с оборудованием
Мобильному роботу нужны лифты, автоматические двери, ворота, конвейеры, зарядные станции, а манипулятору нужны датчики, станки и конвейерные линии. Для этого используют стандартные механизмы промышленной автоматики. Среди распространённых: OPC UA, Modbus, MQTT и обычные цифровые сигналы. Какой из них поддерживает конкретная модель и какая версия ПО, надо уточнять у производителя: каталог таких сведений не содержит.
Здесь есть отдельный риск: оборудование принадлежит другой службе (эксплуатации здания, производству), и ей нужно согласовать подключение к лифту или воротам заранее. Подробнее о подготовке здания в статье Подготовка помещения для робота.
Как подключается 1С
В 1С-системах есть собственные механизмы публикации интерфейсов (например, HTTP-сервисы и веб-сервисы), а также обмен через файлы. Что именно доступно, зависит от конфигурации и версии платформы. Поэтому сценарий «робот ↔ 1С» согласуйте с 1С-специалистом, который знает вашу конфигурацию, и учтите, что часто между роботом и 1С ставят промежуточную систему или шлюз. Тот же принцип относится к ERP других производителей.
Типичные проблемы
Закрытый API. Производитель не раскрывает интерфейс или отдаёт его только своим партнёрам. Тогда подключиться можно лишь через его интегратора, а любое изменение зависит от его очереди. Выясняйте это до покупки.
Документация не на русском. Чаще всего описание интерфейса идёт на английском или китайском. Нужен инженер, который его читает, или перевод с разбором неоднозначностей. Просите документацию в электронном виде и версионируйте её вместе с договором.
Облако за рубежом. Если флот-менеджер работает на серверах производителя, данные о заданиях, картах и камерах идут за пределы вашего периметра. Проверьте, возможна ли локальная установка в вашей сети, как работает система при обрыве связи и как это согласуется с вашей политикой по персональным данным и безопасности. Разные подходы китайских и европейских производителей мы разбирали в статье Китайские или европейские роботы.
Изменения в учётной системе. Обновили WMS, поменяли формат номенклатуры, перестроили адресацию склада, и связка перестала работать. Договоритесь, кто и как проверяет интеграцию после каждого такого изменения.
Версии ПО. Обновление флот-менеджера может изменить интерфейс. Закрепите правило: обновления сначала на тестовом стенде, потом в работе.
Нет тестового стенда. Проверять связку сразу на живом складе рискованно. Попросите стенд или режим симуляции.
Неясно, кто отвечает. Когда поставщик робота, поставщик WMS и интегратор перекладывают вину друг на друга, простой растёт. Нужен один ответственный за связку целиком.
Как заложить интеграцию в договор и пилот
Интеграция это отдельная работа, а не бонус к покупке. Что стоит зафиксировать письменно:
- Перечень обменов. Какие сообщения идут из учёта к роботу и обратно: задание, статус, ошибка, подтверждение.
- Описание интерфейса как приложение к договору, с версией.
- Кто разрабатывает связку и кто принимает её.
- Тестовый стенд и порядок проверки.
- Приёмка по сценариям, а не «по факту подключения»: типичный день, пиковая нагрузка, потеря связи, возврат после сбоя.
- Сопровождение: кто исправляет ошибки интеграции, в какие сроки отвечает и по каким каналам. Конкретные сроки обсуждайте с исполнителем.
- Изменения. Порядок, по которому обновляют ПО робота и учётную систему.
- Данные. Где хранятся, кто имеет доступ, как их забрать при расторжении договора.
В пилот включите минимальный рабочий обмен: хотя бы одно задание из учёта и один отчёт обратно. Так вы убедитесь, что интеграция возможна, до решения о крупной закупке. Как оценивать эффект, смотрите в статье Как посчитать окупаемость робота: затраты на интеграцию нужно включать в расчёт.
Вопросы поставщику и интегратору
Задайте их письменно и сохраните ответы.
Поставщику робота:
- Есть ли открытый интерфейс для внешних систем? Он входит в поставку или лицензируется отдельно?
- На каких языках документация? Есть ли русская?
- Где работает флот-менеджер: на нашем сервере или в облаке производителя? Можно ли работать без выхода в интернет?
- Поддерживается ли стандарт обмена с диспетчером (например, VDA 5050), если вам он нужен?
- Какие способы связи с лифтами, дверями и конвейерами доступны?
- Есть ли готовые коннекторы к WMS или MES, с которыми мы работаем?
- Как вы уведомляете об изменениях в интерфейсе при обновлении?
Интегратору:
- Какой у вас опыт связки с нашей учётной системой? Что показывали на реальных объектах?
- Что будет работать, если связь между системами пропадёт?
- Кто сопровождает связку после запуска и как это закреплено в договоре?
- Из чего складывается оценка трудоёмкости и что может её изменить?
Если на какой-то вопрос нет ответа, это сигнал заложить в проект время на выяснение, а не повод надеяться, что «как-нибудь подключится».
Как оценить трудоёмкость
Не просите итоговую цифру до обследования. Разделите работу на части и оцените каждую:
- анализ вашей учётной системы и данных, которые она может отдать;
- разработка или настройка связки;
- подключение оборудования (лифты, двери, конвейеры);
- тестирование на стенде;
- пилот и доработки по его результатам;
- документация и обучение;
- сопровождение.
Главные факторы, которые меняют объём: открытость интерфейса, число систем, количество видов заданий и исключений, требования к безопасности данных, наличие стенда. Чем меньше типов заданий и чем проще процесс, тем проще оценка.
Что настраивается по классам техники
Общий принцип одинаков, но глубина интеграции разная.
| Класс | Что подключается | Особенности |
|---|---|---|
| AMR и автономные погрузчики | Флот-менеджер, WMS, адреса хранения, ворота, лифты | Основная нагрузка: задания, адреса, зоны, зарядка. Нужны тестовый стенд и протокол при сбое связи |
| Сортировщики | Данные о посылках и направлениях, сканирование, WMS или система сортировки | Критична скорость обмена: правило «посылка → направление» должно отдаваться быстро |
| Коботы и промышленные роботы | MES, контроллеры станков, конвейеры, датчики, ПЛК | Обычно интеграция идёт на уровне ячейки с участием интегратора, а связь с MES: отдельный слой |
| Сервисные и уборочные роботы | Часто нет. Иногда лифты, двери, системы отеля или ресторана | Начинают без интеграции, добавляют при необходимости |
| Больничная логистика | Системы клиники, лифты, двери, заявки на доставку | Дополнительные требования к безопасности и данным; согласование с ИТ клиники |
Подробнее по классам: Складские роботы, AMR-тележка, автономный погрузчик, сортировочный робот, больничная логистика. Если вы только планируете проект на складе, начните с материала Роботизация склада.
Примеры моделей из каталога, для которых вопрос интеграции актуален: Quicktron M100 (AMR), VisionNav VNP15 (автономный погрузчик), Geek+ S20C (сортировщик), Dobot CR20A (паллетайзер) и Noah (больничная логистика). Каталог не описывает их интерфейсы, поэтому доступность API и способы связи уточняйте у поставщика. Для общего сравнения AMR-моделей удобно сравнение AMR-тележек.
Связанные темы
Интеграция: часть большого проекта, поэтому читайте её вместе с остальными материалами серии:
- Программное обеспечение робота: что входит в ПО и кто его обновляет;
- Адаптация робота под задачу: настройка сценариев и оснастки;
- Подготовка помещения для робота: сеть, питание, лифты, двери.
Чек-лист перед подписанием договора
- Определено, какие обмены нужны и с какими системами.
- Получено описание интерфейса и подтверждено, что оно полное и актуальное.
- Понятно, где работает флот-менеджер и что будет при потере связи.
- Назначен один ответственный за связку.
- Есть тестовый стенд или режим симуляции.
- Прописаны приёмка по сценариям и правила обновлений.
- Согласовано подключение к лифтам, воротам и другому оборудованию со службами-владельцами.
- Затраты на интеграцию и сопровождение включены в бюджет.
Модели в каталоге
Характеристики: из открытых материалов производителей (сайты, пресс-релизы, выставки, регистрационные базы) на октябрь 2026 года. Комплектация и внешний вид могут отличаться: сверяйте у поставщика.
Весь каталог →
Частые вопросы
Можно ли запустить робота без интеграции с WMS?
Да, для пилота, для небольших объёмов и для задач, где данные из учёта не нужны, например уборки. Но для склада с потоком заказов ручной ввод станет узким местом. Заранее проверьте, что интеграция возможна, чтобы не упереться в закрытую систему позже.
Что такое флот-менеджер и нужен ли он?
Это программа, которая распределяет задания между мобильными роботами, строит маршруты и управляет зарядкой. Для парка из нескольких машин он нужен почти всегда. Учётная система общается с ним, а не с каждым роботом отдельно.
Как подключить робота к 1С?
Способы зависят от конфигурации 1С и от того, что умеет система робота. Часто между ними ставят промежуточное ПО интегратора или используют обмен через интерфейсы, которые поддерживают обе стороны. Согласуйте решение с 1С-специалистом и поставщиком робота.
Что такое VDA 5050 и нужен ли он?
Это стандарт интерфейса между системой управления и AGV/AMR. Он полезен, когда вы хотите смешивать технику разных производителей или не зависеть от одного диспетчера. Поддержка зависит от модели и версии ПО: уточните её письменно.
Кто отвечает за сбой интеграции?
Это определяется договором. Назначьте одного ответственного за связку целиком и пропишите, кто принимает заявки, в какие сроки отвечает и как проверяет работу после обновлений.
Как проверить документацию на API до покупки?
Запросите описание интерфейса и проверьте его вместе со своим ИТ-специалистом или интегратором. Если документация неполная, не на понятном языке или отдаётся только после оплаты, закладывайте это в риск и в график проекта.
Что дальше
Подбор задаст 2–3 вопроса и покажет подходящие модели разных производителей. Выбранные модели можно сравнить по характеристикам в одной таблице.
Читайте также
Подготовка помещения для робота: полы, проходы, связь, лифтыПодготовка помещения для робота: обследование до покупки, полы и пороги, ширина…