Система диспетчеризации мостового крана и AGV с арбитражем маршрутов

При совместной работе нескольких мостовых кранов и AGV/RGV на одной производственной площадке ключевая задача системы диспетчеризации — безопасное и эффективное распределение задач грузопереработки в условиях ограниченного пространства и времени. Качество арбитража пути напрямую влияет на общую эффективность линии: без алгоритмической диспетчеризации частота конфликтов между устройствами составляет примерно 15–30 раз в час, после оптимизации арбитража пути — снижается до 0–2 раз в час. В данной статье рассматривается инженерная реализация системы диспетчеризации пути для мостовых кранов и AGV/RGV: от сортировки очереди задач, механизма арбитража пути, алгоритма обнаружения конфликтов до динамического перепланирования.

Алгоритм приоритетной сортировки очереди задач

Задачи грузопереработки, поступающие из MES/WMS, сохраняются в очереди задач ПЛК диспетчеризации (кольцевой буфер, емкость 128 записей). Каждая задача содержит ID материала, координаты начальной и конечной точек, приоритет (0–100, для срочных задач — 100), временную метку постановки и требование по сроку выполнения. Приоритетная сортировка использует трехвесовую формулу: Общий приоритет = Приоритет задачи × 0,4 + Коэффициент времени ожидания × 0,3 + Коэффициент срочности срока × 0,3. Коэффициент времени ожидания = (текущее время − время постановки) / стандартное время ожидания (нормализовано до 0–100). Коэффициент срочности срока = затраченное время / общий срок (чем ближе к 1, тем срочнее). Трехвесовой расчет гарантирует, что срочные задачи выполняются вне очереди, но не приводят к бесконечному ожиданию других (чем дольше задача ожидает, тем выше ее позиция в сортировке).

При распределении задач просматриваются первые 20 задач очереди, последовательно проверяются условия назначения: ① есть ли свободный мостовой кран вблизи начальной точки задачи (расстояние по мосту крана ≤10 м); ② есть ли свободный AGV на рабочей позиции начальной точки; ③ отсутствие конфликтующих путей (нет перекрытия с путями уже назначенных задач). Задача, удовлетворяющая всем трем условиям, назначается немедленно; в противном случае она возвращается в очередь ожидания и проверяется заново в следующем цикле. Цикл проверки — 100 мс. Задачи, ожидающие более 60 секунд, назначаются принудительно (конфликтующие задачи автоматически понижаются в приоритете и переводятся в очередь ожидания). Среднее время ожидания задач в системе диспетчеризации Келуде Тяжёлая Промышленность составляет ≤15 секунд, для срочных задач — ≤5 секунд.

Обнаружение конфликтов и динамическое перепланирование

Ключевая сложность координации нескольких устройств — своевременность обнаружения конфликтов и эффективность стратегии арбитража. Обнаружение конфликтов выполняется в два этапа: проверка перекрытия зон (наличие пересечения рабочих областей двух устройств) и анализ временных окон (прогнозирование пересечения траекторий двух устройств в ближайшие 3–5 секунд). Частота проверки — каждые 100 мс, синхронизирована с периодом диспетчеризации. При обнаружении конфликта активируется соответствующая стратегия арбитража по одной из пяти категорий сценариев:

Реализация алгоритма арбитража траекторий

Движок арбитража траекторий — ключевой компонент системы диспетчеризации, отвечающий за принятие решений. Он реализован в циклическом прерывании OB35 (период 100 мс) контроллера Siemens S7-1500. Алгоритм выполняется в три этапа: сначала сопоставление задач и оборудования (описано в предыдущем разделе), затем планирование траектории и, наконец, проверка конфликтов. Для планирования траектории рекомендуется эвристический алгоритм поиска A*: начальная точка — текущее местоположение оборудования, конечная — целевая позиция. Стоимость пути определяется функцией F=G+H, где G — длина пройденного пути, H — эвристическая оценка (максимальное расстояние до цели). Пространство поиска ограничено графом достижимых путей, полученным в результате растрирования карты цеха (расстояние между узлами — 2 м; S7-1500 может хранить до 200 узлов). Один поиск пути на S7-1500 занимает от 2 до 5 мс (зависит от глубины поиска, максимальное количество узлов — 50). Для траекторий AGV, с учётом двустороннего движения и ограничений на разворот, в стоимость пути добавляется штраф за смену направления (каждый поворот увеличивает стоимость на 3 м, что стимулирует использование длинных прямолинейных участков).

Обнаружение конфликтов по временным окнам — вторая линия защиты арбитража траекторий. После назначения пути каждому устройству система разбивает его на последовательность сегментов с временными метками (длина сегмента — 2 м, для каждого сегмента задаётся окно ожидаемого времени прибытия ±0,5 с). При назначении пути новой задаче система последовательно проверяет все сегменты этого пути на пересечение временных окон с уже назначенными путями (т.е. пересечение временных окон двух устройств на одном сегменте пути). Условие пересечения: |T_{устройство А} – T_{устройство Б}| < безопасный интервал (мостовой кран — мостовой кран: 3 с; мостовой кран — AGV: 2 с; AGV — AGV: 1,5 с). При пересечении назначение пути отклоняется, выполняется поиск альтернативного маршрута или ожидание следующего цикла. Массив временных окон хранится в DB-блоке S7-1500 (для каждого устройства резервируется 128 записей сегментов пути, каждая запись — 12 байт, для 12 устройств требуется около 18 КБ памяти).

Финальная матрица решений арбитража траекторий: система диспетчеризации поддерживает матрицу блокировок размером N×N (N — общее количество устройств). Элемент матрицы M[i][j]=0 означает отсутствие конфликта траекторий между устройствами i и j, M[i][j]=1 — наличие конфликта (записывается по результатам проверки временных окон). При арбитраже пары конфликтующих устройств обрабатываются в порядке приоритета: устройство с более высоким приоритетом сохраняет свою траекторию, устройство с более низким приоритетом выполняет перепланирование. Если для устройства с низким приоритетом не найдено альтернативного пути (все достижимые маршруты конфликтуют), оно переходит в режим ожидания с фиксацией причины. Матрица очищается и пересчитывается каждый цикл диспетчеризации (100 мс). В системе диспетчеризации Келуде при работе с 12 устройствами общее время арбитража траекторий не превышает 8 мс (включая проверку временных окон), остальные 92 мс цикла отводятся на связь и логику управления оборудованием.

Архитектура и пример внедрения системы совместной диспетчеризации

Аппаратная архитектура системы диспетчеризации трёхуровневая: полевой уровень (ПЛК мостовых кранов, бортовые контроллеры AGV, контроллеры RGV, подключённые к промышленному сетевому коммутатору через Profinet IRT), уровень диспетчеризации (диспетчерский ПЛК S7-1500 или промышленный ПК, выполняющий функции движка арбитража траекторий и управления очередью задач), уровень управления (серверы MES/WMS, обменивающиеся данными о заказах и задачах с уровнем диспетчеризации через OPC UA). Периоды связи между полевым оборудованием и диспетчерским ПЛК: мостовой кран ≤50 мс (Profinet IRT, джиттер ±1 мкс), AGV ≤100 мс (Profinet RT), RGV ≤50 мс. Связь между диспетчерским ПЛК и MES осуществляется в соответствии с частотой выдачи задач, обычно пакетный обмен каждые 100 мс (объём данных около 2 КБ, включая очередь задач и отчёты о состоянии).

Пример внедрения в цехе окончательной сборки автомобильного завода: 12 мостовых кранов (в т.ч. 5 типа LD, 3 типа QD, 4 консольных крана) + 24 AGV (16 скрытого типа, 8 вилочных) + 8 RGV, всего 44 единицы оборудования, работающих совместно на одной производственной площадке (примерно 200 м × 80 м). До внедрения системы частота конфликтов при ручном управлении составляла около 20 раз/час (в пиковые периоды до 40 раз/час), среднее время ожидания задачи — 45 с. После внедрения системы диспетчеризации Келуде (диспетчерский ПЛК на базе S7-1500 CPU 1516-3 PN/DP с модулем CP1543-1 для связи по OPC UA) частота конфликтов снизилась до 0–2 раз/час, среднее время ожидания задачи — до 15 с, эффективность диспетчеризации повысилась на 42% (по количеству выполненных транспортных задач в час). Проект от обследования до ввода в эксплуатацию занял 8 недель (включая 3 недели на конфигурирование ПО, 2 недели на пусконаладку на объекте и 1 неделю на комплексное тестирование).

Проектирование масштабируемости: система диспетчеризации имеет модульную архитектуру: для добавления нового устройства достаточно добавить запись конфигурации в DB-блок диспетчерского ПЛК (около 50 байт на устройство) и настроить тип устройства и адрес связи на HMI. Один контроллер S7-1500 может управлять ≤12 устройствами (ограничение по времени сканирования программы и коммуникационным ресурсам). При превышении 12 устройств добавляется второй диспетчерский ПЛК для сегментированной диспетчеризации — по зонам завода (например, ПЛК зоны А управляет 6 мостовыми кранами и 10 AGV, ПЛК зоны Б — 8 RGV и 14 AGV). Обмен данными о граничных задачах между зонами осуществляется через PN/PN Coupler или промышленный Ethernet. Система диспетчеризации Келуде поддерживает расширение до 64 устройств на одном заводе (каскадное подключение 4 диспетчерских ПЛК).

Частые вопросы по системе диспетчеризации