Мультиагентный конструктор и планировщик транспортных сетей

МУЛЬТИАГЕНТНЫЙ КОНСТРУКТОР И ПЛАНИРОВЩИК
ТРАНСПОРТНЫХ СЕТЕЙ
В.В. Андреев1, М.В. Андреев2, С.В. Батищев2, Т.В. Искварина2, П.О. Скобелев2
1
Институт проблем управления сложными системами РАН
443020, Самара, ул. Садовая, 61
cscmp@iccs.ru
тел: +7 (8462) 32-39-27, факс: +7 (8462) 33-27-70
2
ООО НПК «Маджента Девелопмент»
443110, Самара, ул. Осипенко, 1а
bat@magenta-technology.ru
тел: +7 (8462) 70-66-84; 70-66-85
Ключевые слова: планировщик, мультиагентные переговоры
Abstract
Key requirements for transportation logistics planning systems are proposed. Existing product
features are analyzed. Architecture and algorithms of multiagent scheduling system based on
J2EE architecture are explained.
Введение
Системы планирования и поддержки исполнения составленного плана являются неотъемлемой частью современной информационной системы поддержки работы транспортной компании.
Можно выделить две категории потребителей таких систем:
• Операторы и диспетчеры: составляют план перевозок на определенный период, отслеживают исполнение плана, изменяя план, если этого требуют изменившиеся условия среды.
• Консультанты и аналитики: проектируют или оптимизируют сеть поставок компании,
описывая ограничения предметной области и моделируя планирование/исполнение перевозок.
Операторы и диспетчеры предъявляют следующие требования к системе планирования:
• Планировать поток заказов на множество доступных транспортных средств. Поддерживать
при планировании ограничения предметной области (совместимости грузовиков и грузов,
совместимости грузовиков и пунктов погрузки/разгрузки, пропускная способность склада
и другие).
• После формирования расписания пользователь должен иметь возможность инициировать
пересмотр расписания, если решение его не устраивает. Такое часто происходит, если не
все ограничения или критерии диспетчера учтены в системе (см. [1]). Например, диспетчер
может считать, что целесообразно направить грузовик нужного типа в место скопления потенциальных встречных перевозок (см. [2]). В этом случае система должна предложить ему
новый вариант расписания, учтя пожелания пользователя, даже если это ухудшит вариант
по формальным критериям системы.
• Возможность ввести новые заказы (или изменить существующие) после составления расписания.
• На фазе исполнения расписания система должна поддерживать «вбрасывание» в расписание новых заказов или событий реального мира (например, опоздание, отмена заказа). При
254
этом часто вступают в силу целый ряд новых ограничений предметной области (например,
по переформированию грузов, уже подготовленных для погрузки).
• Система должна отвечать требованиям решения уровня предприятия (масштабируемость,
надежность, безопасность).
Консультанты и менеджеры предъявляют следующие требования к системе проектирования сети:
• Возможность описать понятия, типы отношений и правила принятия решений без перепрограммирования системы.
• Возможность сконструировать сеть компании на основе заданных понятий и правил. Для
каждого ресурса могут быть заданы его уникальные свойства и правила.
• Возможность смоделировать поведение сети, вводя в нее различные потоки заказов на перевозку.
• Возможность использовать модель сети в процессе тактического планирования.
1 Архитектура и принципы работы мультиагентого конструктора и планировщика
транспортных сетей
Как было показано в [2], для решения задач транспортной логистики применим и эффективен мультиагентный подход. На основе этого подхода компанией Magenta был спроектирован набор компонент для решения задач транспортной логистики (см. рисунок 1).
Рисунок 1 – Архитектура мультиагентной системы для планирования перевозок
255
Разработанные компоненты сгруппированы в два программных пакета, отвечающих требованиям описанных выше групп пользователей:
• Планировщик транспортных сетей. Включает все перечисленные на рисунке модули кроме
средств моделирования. Конструктор онтологий планировщика имеет ограниченную
функциональность и адаптирован под нужды оператора (небольшие изменения в бизнесправилах без существенной переработки классов объектов и отношений).
• Конструктор транспортных сетей. Включает все перечисленные на рисунке модули кроме
средств управления событиями и интерфейса для мобильных устройств. Конструктор онтологий в этом пакете имеет полную функциональность для описания разнообразных
транспортных сетей.
Разработанные компоненты основаны на технологии J2EE и используют реляционную базу данных для хранения состояния агентов, что позволило обеспечить масштабируемость и
надежность разработанного решения (см. [3]).
Основным модулем комплекса является система времени исполнения для поддержки планирования. Ее основные компоненты представлены на рисунке 2:
Рисунок 2 – Архитектура система времени исполнения для поддержки планирования
Алгоритм работы системы разбит на несколько этапов, которые представлены на блоксхеме (рисунок 3).
На каждом из этапов агенты действуют в соответствии со своими индивидуальными стратегиями и протоколами переговоров. Так, например, агент компании может иметь следующие
стратегии:
256
Рисунок 3 – Основные этапы работы системы
•
•
Начинать планирование с наиболее жестко ограниченных заказов (например, с
тех, которые могут быть перевезены исключительно на грузовике с холодильным агрегатом).
Начинать планирование с наиболее дальних заказов (выгодно, если хотим повысить устойчивость расписания к изменениям, так как выполнять перепланирование вблизи базы обычно легче). Альтернатива – начинать планирование с
наиболее близких заказов (выгодно, если хотим иметь открытые слоты для
встречных перевозок).
2 Протоколы переговоров для решения задач планирования и перепланирования
Рассмотрим основные принципы реализации переговоров в рассматриваемой системе на
примере переговоров агента нового заказа с остальными участниками.
Эти переговоры для увеличения производительности были разбиты на несколько этапов
(см. рисунок 4):
На каждом из шагов выполняются следующие действия:
• Предварительный «матчинг».
• Агент заказа проверяет соответствие каждого ресурса своим онтологическим критериям и выполняет их сортировку.
• Агент заказа запрашивает каждый ресурс, хочет ли он планировать заказ. Ресурс проверяет свои онтологические правила (например, если он загружен на более чем 90 процентов, то может отказаться) и отвечает заказу.
257
Предварительный
«матчинг»
Построение плана посещения точек:
Планирование в открытые слоты
Планирование со смещением заказов
Планирование с обменом заказов
Уточнение времени посещения каждой точки
в соответствии с интересами всех агентов
методом минимальных уступок
Планирование заказов, с которыми был выполнен обмен
Финальная проверка варианта
Рисунок 4 – Шаги переговоров агента нового заказа с другими участниками
•
Построения плана посещения точек.
• Агент заказа запрашивает у агента ресурса разрешение на размещение в «открытый
слот».
• Агент ресурса ищет варианты размещения точек погрузки/выгрузки заказа.
Агент ресурса проверяет найденный варианты по своим стратегиям (например,
отвергать варианты с неэффективной географией) и ограничениям (например,
по порядку загрузки/выгрузки) и отбирает лучшие.
• Агент ресурса возвращает вариант заказу, и тот принимает решение, продолжать ли поиск дальше.
• Агент заказа запрашивает у агента ресурса разрешение на размещение «со сдвигом» (если на предыдущем шаге решение его не удовлетворило).
• Агент ресурса запрашивает агентов всех размещенных на нем транспортных инструкций, согласны ли они на сдвиг. Заметим, что имеется возможность сокращения списка сдвигаемых агентов (например, агенты только этого рейса).
• Агенты размещенных заказов имеют право отказаться от сдвига, если их стратегии/эвристики не разрешают это (например, заказ большого объема менее склонен к сдвигу, чем небольшой заказ).
• Агент ресурса ищет варианты размещения со сдвигом согласившихся агентов в
пределах того же ресурса. Агент ресурса проверяет найденный варианты по
своим стратегиям и ограничениям и отбирает лучшие.
• Агент ресурса возвращает вариант заказу, и тот принимает решение, продолжать ли поиск дальше.
• Агент заказа запрашивает у агента ресурса разрешение на размещение «с обменом»
(если на предыдущем шаге решение его не удовлетворило). Переговоры выполняются аналогично предыдущему этапу. Планирование отличается тем, что если ка-
258
кой-то из размещенных заказов «мешает» размещению нового, у него запрашивается разрешение переместить конфликтный заказ на новый ресурс (с согласия ресурса
и заказа).
• Уточнение времени размещения каждой точки маршрута методом минимальных уступок.
• Агент заказа предлагает оптимальное время со своей точки зрения (например, стараясь не менять свое старое положение до сдвига или целясь в свое целевое время,
если оно задано).
• Агент ресурса проверяет по своей стратегии, является ли такое размещение приемлемым (типичный критерий при этом – время простоя). Если нет, то ресурс возвращает свой вариант размещения в рамках окна заказа.
• Агент заказа проверяет по своей стратегии, является ли такое размещение приемлемым, и если нет, то просит ресурс об уступке.
• Агент ресурса определяет по стратегии, хочет ли он продолжать переговоры и если, да, то предлагает шаг на встречу (точку менее выгодную по времени простоя, но
более близкую к начальной точке заказа, шаг определяется стратегией).
• Агент заказа проверяет, удовлетворяет ли его найденное решение и хочет ли он
продолжать переговоры (например, по максимальному количеству шагов).
Аналогично переговоры выполняются между агентом ресурса и склада.
Заключение
Описанный алгоритм демонстрирует приемлемые результаты при планировании расписаний «с нуля» и очень эффективен для локального пересмотра расписаний. Это позволяет использовать систему для решения задач, которые ранее требовали ручного планирования.
Безусловно, есть целый ряд направлений для развития системы:
•
Поддержка вторичной логистики (водитель, фура и тягач как отдельные дополнительные
объекты планирования со своими ограничениями и предпочтениями).
•
Поддержка встречных предложение и перекрывания ограничений (загрузить на одну паллету больше, чем положено по нормативной емкости без превышения жесткого ограничения по весу, но сэкономить дополнительный рейс грузовика).
•
Поддержка механизмов адаптации и обучения. Кластеризация похожих заказов и ресурсов
в группы. Оценка эффективности стратегий и их настройка на основе опыта.
Список литературы
[1] Бадашкин В.А., Косяков С.В Опыт создания системы планирования грузоперевозок по городу с использованием ГИС / В журнале «Информационный бюллетень. ГИС-Ассоциация» №3,2000, с.61-62.
[2] С.Батищев, К. Ивкушкин, Т. Искварина, В. Никифоров, П. Скобелев. Анализ возможности и эффективности применения мультиагентных технологий в динамических задачах логистики. - Материалы
этой конференции.
[3] В.Андреев, C. Батищев, Т. Искварина, П. Скобелев. Инструментальные средства для разработки
мультиагентных систем промышленного масштаба. - Материалы этой конференции.
259