AGV на складе и в цехе обычно покупают не ради красивой техники. Их покупают, чтобы материал приезжал вовремя: тара к линии, полуфабрикат на участок, готовая продукция в зону отгрузки, пустая тележка обратно в оборот. Но после первых успешных рейсов появляется вопрос, который редко звучит в презентациях: кто владеет данными о движении?
Логисту важно видеть заказ, маршрут, приоритет, SLA доставки и остатки. Оператору цеха - готова ли точка приема, не заблокирована ли зона, почему AGV стоит у линии и можно ли продолжать выпуск. Инженеру АСУ ТП - какие статусы должны попасть в SCADA, какие сигналы идут в ПЛК, что делать при потере связи и где фиксировать аварии. MES интересует производственный контекст: какая партия ждет материал, какая операция задержана, как простой повлиял на сменный результат.
Если эти границы не договорить заранее, одна и та же величина начинает жить в четырех трактовках. Для WMS задача уже выполнена, потому что AGV привез паллету в координату. Для SCADA линия еще не готова, потому что датчик в приемной позиции не подтвердил наличие. Для MES операция висит в задержке. Для логиста все это выглядит как “робот приехал, но производство снова не забрало”.
Эта статья не про устройство AGV, навигацию и батареи. Речь о данных: кто является источником истины, что показывать оператору цеха, что нужно логисту и где проходит граница между WMS, MES, SCADA и ПЛК.
Короткая схема ролей
В устойчивой архитектуре каждая система отвечает за свой слой решений:
Эта схема кажется простой, пока не возникает первый спор о статусе “доставлено”. Для склада доставлено - это прибытие в нужную ячейку или зону. Для производства доставлено - это материал принят в технологическую точку и его можно использовать. Для ПЛК доставлено - это сработали нужные датчики, выполнены межблокировки и оборудование безопасно перешло в следующий шаг.
Поэтому главное правило звучит так: данные должны принадлежать той системе, которая отвечает за решение и последствия ошибки. Если ошибка может привести к физическому риску, источник должен быть ближе к ПЛК и SCADA. Если ошибка связана с запасами, маршрутом и складской операцией - ближе к WMS. Если ошибка влияет на партию, операцию и отчет производства - ближе к MES.
WMS: владелец складского намерения
WMS отвечает за складскую логику: откуда взять груз, куда его доставить, какой приоритет у задачи, какие правила хранения и отгрузки действуют. Для WMS AGV - это исполнитель перемещения, а не технологический объект линии.
Типовые данные WMS:
•идентификатор складской задачи;
•источник и назначение;
•номенклатура, партия, единица хранения;
•приоритет и плановый срок доставки;
•статус складской операции;
•подтверждение приемки или отгрузки в складском контуре.
WMS не должна напрямую решать, можно ли линии принять паллету в конкретную секунду, если это зависит от датчиков, ограждений, конвейера или состояния оборудования. Она может запросить доставку, но физическое разрешение принимает контур цеха.
Для логиста интерфейс должен отвечать на свои вопросы: где груз, почему задержка, какой AGV выполняет задачу, какой SLA нарушен, нужна ли ручная операция. Ему не нужно видеть все аварийные теги ПЛК или каждую межблокировку шкафа управления. Избыточная техническая детализация только мешает управлять потоком.
Fleet manager: владелец движения AGV
Система управления флотом отвечает за назначение робота, маршрут, состояние AGV, заряд, занятость, ожидание на перекрестке, ручной режим, ошибку навигации. Это не WMS и не SCADA, хотя обе системы читают ее данные.
Fleet manager обычно знает:
•какой AGV назначен на задачу;
•где он находится;
•в каком статусе задача: назначена, в пути, ожидает, выполнена, отменена, ошибка;
•почему робот остановился;
•доступен ли AGV для новой задачи;
•нужен ли оператору ручной recovery.
Но fleet manager не всегда понимает производственный смысл задержки. Он может честно сообщить: “робот ожидает у точки выгрузки”. А вот почему точка занята - линия не готова, оператор не подтвердил приемку, конвейер заблокирован, идет мойка или нет разрешения от ПЛК - это уже контекст SCADA/MES.
В старой статье про AMR/AGV на производстве мы разбирали запуск флота, safety-зоны и traffic management. Здесь важно другое: fleet manager не должен становиться владельцем всех данных только потому, что через него виден робот. Он владеет движением, но не складом, не партией и не физической готовностью линии.
MES: владелец производственного контекста
MES связывает перемещение с производством: какая операция ждет материал, какая партия задерживается, какой участок не может продолжать выпуск, как это отражается в сменном отчете. Если WMS отвечает “где груз”, MES отвечает “зачем этот груз нужен производству”.
Типовые данные MES:
•производственный заказ, партия, операция;
•потребность линии в материале;
•статус операции: ожидает материал, выполняется, задержана, завершена;
•связь доставки с выпуском, простоем, отклонением;
•факт использования материала в производстве;
•отчетность по партии и смене.
MES не должна командовать роботом на уровне маршрута и не должна открывать ворота или включать конвейер. Но она должна получать события, которые объясняют влияние логистики на производство: материал запрошен, задача создана, AGV прибыл, приемка подтверждена, операция началась, задержка закрыта.
Похожую границу мы уже проводили в материале «MES и АСУ ТП: где заканчивается рецепт в ПЛК». Там речь шла о рецепте и партии, здесь - о логистике. Принцип тот же: MES владеет производственным контекстом, а физический факт подтверждает нижний уровень.
SCADA: окно оператора цеха, а не складская карта
SCADA нужна не для того, чтобы оператор цеха смотрел полный складской маршрут AGV. Ему важнее понимать, как движение влияет на его участок прямо сейчас.
На экране оператора цеха полезно показывать:
•ожидается ли доставка материала на линию;
•какой статус у ближайшей точки приема: свободна, занята, заблокирована, требует подтверждения;
•AGV прибыл, ожидает или ушел с ошибкой;
•есть ли блокировка со стороны ПЛК;
•что нужно сделать оператору: подтвердить приемку, освободить точку, перевести узел в ручной режим, вызвать ответственного;
•какие события попали в журнал смены.
А вот полный список складских задач, длинные маршруты, остатки по складу и общая загрузка флота оператору цеха чаще всего не нужны. Если SCADA превращается в мини-WMS, интерфейс перегружается, а смена перестает видеть главное: готовность оборудования и ближайшее действие.
SCADA должна быть честной к физике. Если WMS считает, что паллета доставлена, но датчик на приемной позиции ее не видит, оператору нельзя показывать “успешно” без оговорки. Правильнее показать расхождение: задача доставки завершена, приемка линией не подтверждена. Тогда смена понимает, где искать проблему.
ПЛК: источник физического факта
ПЛК не владеет складской задачей, не планирует маршруты и не считает SLA. Его зона - физическое состояние оборудования и безопасное выполнение команд.
ПЛК обычно подтверждает:
•свободна ли точка приема;
•открыт ли доступный технологический путь;
•сработали ли датчики наличия;
•разрешена ли подача на конвейер;
•нет ли аварийной блокировки;
•можно ли принять груз;
•завершено ли физическое действие.
Если SCADA показывает “AGV прибыл”, это событие может прийти от fleet manager. Но если система показывает “материал принят линией”, это уже должно опираться на физический факт: датчики, подтверждение механизма, разрешения и межблокировки. Иначе в отчете появится красивая логистика, а в цехе - пустая точка приема.
ПЛК также должен защищать оборудование от некорректных команд верхнего уровня. Если WMS или MES требует выгрузку, а зона занята или нет безопасного разрешения, контроллер должен отказать и вернуть понятную причину. Это не конфликт с верхними системами, а нормальная граница ответственности.
Что показывать оператору цеха, а что логисту
Одна из ошибок проекта - попытка сделать “единый экран для всех”. В итоге логист видит слишком много аварий оборудования, а оператор цеха - слишком много складских деталей. Рабочий подход другой: данные общие, представления разные.
Эта таблица особенно важна на этапе проектирования. Если ее не согласовать до разработки экранов, каждая сторона потом будет просить “добавить еще пару полей”, и интерфейсы быстро потеряют фокус.
Карта владельцев данных
Полезно заранее договориться, кто является источником истины для каждого ключевого события.
Главное здесь - не просто “куда писать тег”, а как потом расследовать спор. Если паллета пропала из статуса, доставка зависла, линия встала, а каждая система хранит свой ID без связи с соседними, разбор превращается в ручное сопоставление логов.
Общий ID важнее красивого дашборда
Для AGV-интеграции критично иметь общую сквозную идентификацию. Не обязательно один ID на все случаи, но между ними должна быть связь:
•TaskId складской задачи;
•TransportOrderId задания флоту;
•AgvId конкретного робота;
•LineId или точка назначения;
•BatchId или производственная операция, если доставка связана с выпуском;
•временные метки создания, принятия, прибытия, физической приемки и закрытия.
Без этого можно построить красивые экраны, но не построить доверие к данным. Логист будет видеть, что задача закрыта. Оператор будет говорить, что материал не принят. MES будет фиксировать задержку. А инженер АСУ ТП будет искать, какой именно рейс соответствует какой аварии в журнале.
Если предприятие идет в сторону единого пространства данных, такие связи лучше проектировать не как набор случайных интеграций, а как модель событий. Подход с единым контекстом мы разбирали в статье «Unified Namespace на практике: единое пространство имен без боли от тегов». Для intralogistics это особенно полезно: много систем, много статусов, много владельцев одного физического потока.
Типовые конфликты на стыке склада и цеха
WMS закрыла задачу, но линия не приняла материал. Значит, событие “доставлено” и событие “принято производством” смешали в одно. Нужно разделить прибытие AGV, выгрузку, физическое подтверждение и производственную приемку.
Оператор видит аварию AGV, но не понимает, что делать. SCADA получила статус ошибки, но без сценария действия. Для смены нужен не просто код, а понятное состояние: освободить точку, вызвать логиста, перевести узел в ручной режим, ждать восстановления связи.
Логист видит задержку, но не понимает причину. Fleet manager сообщает ожидание у точки, но не получает от SCADA причину: зона занята, нет разрешения ПЛК, линия в останове, оператор не подтвердил готовность. Нужна классификация причин простоя.
MES считает операцию задержанной, но WMS не считает это проблемой. Для склада SLA еще не нарушен, а для производства окно уже критично. Значит, приоритет должен учитывать не только маршрут, но и производственный контекст.
Инженер АСУ ТП получает просьбу “просто вывести все AGV в SCADA”. Это почти всегда плохая постановка. Выводить нужно не все, а то, что влияет на участок, безопасность, действия оператора и расследование событий.
Мини-регламент перед разработкой экранов и обмена
Перед тем как рисовать SCADA-экран или писать интеграцию, команде стоит пройти короткий список вопросов.
1.Какая система создает задачу перемещения: WMS, MES или отдельный диспетчер?
2.Кто назначает AGV и кто меняет маршрут?
3.Какой статус означает “AGV прибыл”, а какой - “материал принят линией”?
4.Какие сигналы ПЛК подтверждают физическую готовность точки приема?
5.Какие статусы должны быть видны оператору цеха, а какие только логисту?
6.Какие причины задержки различаются в отчетах: робот, маршрут, зона, производство, оператор, связь?
7.Как связаны TaskId, AgvId, производственная операция и временные метки?
8.Что происходит при потере связи между WMS, fleet manager, SCADA и ПЛК?
9.Где хранится журнал ручного вмешательства и кто имеет право закрыть задачу вручную?
10.Какие сценарии проверяются на FAT/SAT: прибытие, отказ приемки, занятая зона, отмена задачи, потеря связи?
Этот регламент не заменяет техническое задание, но помогает быстро найти размытые зоны ответственности. Если ответ на половину вопросов звучит как “потом решим”, проект еще не готов к устойчивой эксплуатации.
Где здесь место СТАБУР
В таких проектах контроллер или панель оператора не должны притворяться WMS или MES. Их роль практичнее: собрать физический факт, показать оператору понятное состояние, отработать межблокировки, передать события в верхний уровень и не потерять управляемость участка при сбоях связи.
Для локальных узлов приема, конвейерных точек, небольших буферов, шлюзов между складом и производством удобно, когда ПЛК/панель работают как аккуратная граница между физическим оборудованием и верхними системами. В проектах на базе решений СТАБУР это можно закладывать как отдельный слой: операторский экран участка, статусы готовности, журнал событий, обмен с SCADA/MES/WMS по согласованной модели.
Смысл не в том, чтобы “все хранить в ПЛК”. Смысл в том, чтобы нижний уровень давал достоверный физический факт, а верхние системы не спорили о том, что произошло на самом деле.
Итог
AGV в цехе и на складе - это не только мобильная техника. Это поток данных между логистикой, производством и АСУ ТП. Если заранее не определить владельцев, один и тот же статус будет означать разные вещи для WMS, MES, SCADA и ПЛК.
Логисту нужен маршрут, приоритет, SLA и статус груза. Оператору цеха - готовность точки, ближайшее действие и понятная причина блокировки. MES нужен производственный контекст. SCADA нужна честная картина участка. ПЛК отвечает за физический факт и безопасность.
Когда эти роли разделены, AGV перестает быть отдельным “роботом на складе” и становится нормальной частью intralogistics: доставка связана с производством, статусы понятны смене, а спорные ситуации можно расследовать по единым ID и событиям.
Обсуждение