close

Вход

Забыли?

вход по аккаунту

?

10131.Мультиагентная технология управления мобильными ресурсами в режиме реального времени.

код для вставкиСкачать
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Федеральное агентство связи
Государственное образовательное учреждение
высшего профессионального образования
ПОВОЛЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ТЕЛЕКОММУНИКАЦИЙ И ИНФОРМАТИКИ
ЭЛЕКТРОННАЯ
БИБЛИОТЕЧНАЯ СИСТЕМА
Самара
1
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ФЕДЕРАЛЬНОЕ АГЕНТСТВО СВЯЗИ
ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
ПОВОЛЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ТЕЛЕКОММУНИКАЦИЙ И ИНФОРМАТИКИ
КАФЕДРА ИНЖЕНЕРИИ ЗНАНИЙ
А.В.Иващенко, А.Н.Лада, Е.В.Симонова,
П.О.Скобелев
МУЛЬТИАГЕНТНАЯ ТЕХНОЛОГИЯ
УПРАВЛЕНИЯ МОБИЛЬНЫМИ РЕСУРСАМИ
В РЕЖИМЕ РЕАЛЬНОГО ВРЕМЕНИ
Учебное пособие
САМАРА
ПГУТИ
2011
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
УДК 004.9 (075)
ББК 32.97
Мультиагентная технология управления мобильными ресурсами в режиме реального времени / А.В.Иващенко, А.Н.Лада,
Е.В.Симонова, П.О.Скобелев. Поволжский государственный университет телекоммуникаций и информатики. Самара, 2011 –
177 с.
Учебное пособие предназначено для студентов, обучающихся
по специальности 230105 – «Программное обеспечение вычислительной техники и автоматизированных систем». Рекомендуется использовать учебное пособие при изучении курсов «Системы
искусственного интеллекта», «Мультиагентные системы» и
«Мультиагентный подход в управлении распределенными системами». Включает разделы, которые подробно описывают современное состояние и методы адаптивного планирования, мультиагентный подход к решению задач динамического планирования
ресурсов в реальном времени, архитектуру и реализацию мультиагентной системы управления транспортными ресурсами. Теоретический материал иллюстрируется большим количеством
примеров динамического планирования. Учебное пособие содержит контрольные вопросы и упражнения по всем разделам.
Учебное пособие разработано на кафедре инженерии знаний
совместно с научно-производственной компанией «Разумные решения». Рассматриваемая мультиагентная система и лабораторный практикум не могут копироваться или воспроизводиться в
любых формах без специального разрешения.
Табл. 25. Ил. 124. Библиогр.: 88 назв.
Печатается по решению редакционно-издательского совета Поволжского государственного университета телекоммуникаций и
информатики
Рецензенты: д.т.н., проф. Прохоров С.А.
д.т.н., проф. Смирнов С.В.
© Поволжский государственный университет
телекоммуникаций и информатики, 2011
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
СОДЕРЖАНИЕ
Введение ................................................................................................................. 6
1 МЕТОДЫ И АЛГОРИТМЫ ПЛАНИРОВАНИЯ РЕСУРСОВ ...................... 10
1.1 Современная постановка задачи управления мобильными
ресурсами в режиме реального времени .......................................................... 10
1.2 Особенности планирования ресурсов в транспортнологистической компании ................................................................................... 12
1.3 Обзор алгоритмов распределения ресурсов .............................................. 14
1.3.1 Списочные алгоритмы ........................................................................... 15
1.3.2 Алгоритм имитации отжига ............................................................... 16
1.3.3 Генетические алгоритмы ...................................................................... 16
1.3.4 Мультиагентный подход ....................................................................... 18
1.3.5 Сравнительный анализ алгоритмов распределения ресурсов .......... 20
2 МУЛЬТИАГЕНТНАЯ МОДЕЛЬ АДАПТИВНОГО
ПЛАНИРОВАНИЯ МОБИЛЬНЫХ РЕСУРСОВ .............................................. 25
2.1 Метод адаптивного планирования ............................................................. 25
2.1.1 Сеть потребностей и возможностей ................................................. 25
2.1.2 Метод компенсаций ............................................................................... 30
2.2 Обзор архитектуры мультиагентных систем............................................. 33
2.3 Мультиагентная платформа планирования ............................................... 39
2.3.1 Онтология – модель знаний предметной области ............................. 39
2.3.2 Агенты мира транспортной логистики.............................................. 45
2.3.3 Алгоритм переговоров агентов ............................................................ 48
2.3.4 Реализация мультиагентной платформы планирования
ресурсов ............................................................................................................ 54
2.4 Примеры адаптивного планирования заказов в реальном времени........ 56
3 МУЛЬТИАГЕНТНАЯ СИСТЕМА УПРАВЛЕНИЯ
ТРАНСПОРТНЫМИ РЕСУРСАМИ (МАС УТР).............................................. 60
3.1 Назначение системы..................................................................................... 60
3.2 Установка и запуск системы ....................................................................... 61
3.3 Начало работы с системой........................................................................... 62
3.3.1 Интерфейс и главное окно системы .................................................... 62
3.3.2 Ввод новой заявки ................................................................................... 65
3.3.3 Последовательность действий менеджера по обработке
заявки ................................................................................................................ 67
3.4 Управление.................................................................................................... 69
3.4.1 Управление ресурсами ............................................................................ 69
3.4.2 Управление заявками .............................................................................. 79
3.4.3 Справочники ............................................................................................ 94
3.4.4 Мониторинг ............................................................................................ 111
3.4.5 Отчеты ................................................................................................... 118
3.4.6 Редактор правил..................................................................................... 122
3.4.7 Шаблоны печатных форм ..................................................................... 126
4 Цели, задачи и содержание лабораторного практикума ................................ 129
5 Лабораторный практикум.................................................................................. 131
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
5.1 Исходная информация для планирования ................................................. 131
5.2 Рассчитываемые показатели планирования ресурсов .............................. 133
5.3 Лабораторная работа №1. Создание заявок, построение
начального плана и последовательное планирование заявок ........................ 134
5.3.1 Создание заявок и построение начального плана ............................... 134
5.3.2 Сценарий последовательного планирования заявок ........................... 140
5.3.3 Индивидуальные задания ....................................................................... 145
5.4 Лабораторная работа №2. Подбор ресурса с минимальным
холостым ходом .................................................................................................. 145
5.4.1 Сценарий планирования заявок на ресурсы с минимальным
холостым ходом .............................................................................................. 145
5.4.2 Индивидуальные задания ....................................................................... 150
5.5 Лабораторная работа №3. Перепланирование заявок по ресурсам
в случае появления более выгодной заявки..................................................... 150
5.5.1 Сценарий перепланирования ресурсов с вытеснением заявок ........... 151
5.5.2 Индивидуальные задания ....................................................................... 156
5.6 Лабораторная работа №4. Планирование заявок по ресурсам в
случае недоступности ресурса .......................................................................... 156
5.6.1 Сценарий перепланирования ресурсов при недоступности
ресурса .............................................................................................................. 157
5.6.2 Индивидуальные задания ....................................................................... 160
5.7 Лабораторная работа №5. Планирование заявок на
предпочитаемые ресурсы ................................................................................. 160
5.7.1 Сценарий планирования заявок на предпочитаемые ресурсы ........... 161
5.7.2 Индивидуальные задания ....................................................................... 165
5.8 Лабораторная работа №6. Планирование неприбыльной заявки ............ 165
5.8.1 Сценарий раздельного планирования неприбыльной и
прибыльной заявок ........................................................................................... 167
5.8.2 Сценарий совместного планирования неприбыльной и
прибыльной заявок ........................................................................................... 172
5.8.3 Индивидуальные задания ....................................................................... 176
5.9 Контрольные вопросы.................................................................................. 177
Заключение ............................................................................................................ 178
Библиографический список ................................................................................. 179
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ВВЕДЕНИЕ
Широкое распространение мобильных телефонов и других «наладонных»
устройств в последнее время внесло существенный вклад в развитие техносферы. Стремительный прогресс в области Интернет систем, мобильной связи и
спутниковой GPS/ГЛОНАСС навигации открывают новые возможности для
решения многих проблем в поддержании коллективного взаимодействия пользователей автоматизированных систем в задачах управления распределением
ресурсов в режиме реального времени.
Современный сотовый телефон все чаще воспринимается не только как
средство связи, но и как полнофункциональный компонент сложной мехатронной системы автоматизации планирования и контроля исполнения задач. Простота использования мобильных устройств и широкие возможности по их интеграции с системами телеметрии позволяют решать задачи динамического
управления мобильными ресурсами в транспортной логистике.
В то же время в распределенных автоматизированных системах управления становится все важнее привлечение участников-исполнителей заданий в
процесс коллективного взаимодействия по принятию управленческих решений.
С учетом высокой динамики и изменчивости бизнес-процессов становится
крайне важно поддерживать постоянную связь между исполнителями и своевременно получать информацию о происходящих событиях.
В связи с этим, весьма актуальной является задача применения новых методов и средств динамического управления мобильными ресурсами, позволяющих автоматически создавать и изменять формирующееся расписание
средствами мобильного устройства (например, телефона) по событиям с учѐтом
структуры и взаимосвязей задач и возможности их исполнения в зависимости
от местонахождения пользователя. При этом особое внимание следует уделять
обеспечению удобства, гибкости и эффективности инструментария динамического планирования, для чего необходимо использовать возможности современных мультиагентных технологий и онтологий.
На сегодняшний день задача автоматизации планирования мобильных ресурсов является одной из наиболее актуальных в транспортной логистике. При
этом важнейшим аспектом управления является планирование распределения
имеющихся в системе ресурсов, при котором наилучшим образом достигается
выполнение поставленных перед системой целей.
Сложные сети поставок включают различные порты и склады, ресурсы с
различными характеристиками и заказы на транспортировку различных типов
грузов. Сложность задачи транспортной логистики обусловлена следующими
требованиями:
­ планирование в реальном времени;
­ большие объемы (> 1000 заказов ежедневно, > 100 пунктов назначения, > 50
транспортных средств);
­ «плавающие» и «стягивающиеся» временные окна;
­ заказы меньшего объема, чем один грузовик, требующие эффективной консолидации;
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
необходимость поиска нетрадиционных решений;
интенсивные перегрузки товара на складах;
обмен прицепами;
множественные ограничения по типам, доступности, габаритам, совместимости грузов и транспортных средств;
­ необходимость индивидуального подхода к крупным клиентам;
­ собственные и арендованные транспортные средства;
­ жѐсткие и гибкие графики доставки грузов;
­ зависимые расписания (прицепов, водителей и др.);
­ экономическая оценка вариантов в реальном времени;
­ постоянная эволюция транспортной сети.
Обозначенные проблемы достаточно специфичны и во многом зависят от
конкретной компании. Логика принятия решения агентами тоже во многом определяется требованиями каждой конкретной компании. При этом основная
сложность подобного рода решений связана с неопределѐнностью требований и
логики принятия решений, которая субъективна и по большей части зависит от
менеджеров компании.
Режим реального времени – это специальный режим работы автоматизированной системы обработки информации и управления, при котором учитываются ограничения на временные характеристики функционирования. Назначение систем, работающих в режиме реального времени, – взаимодействие с
объектами внешнего (по отношению к системе) мира в темпе процессов, протекающих в этих объектах.
В математике, в области исследования операций, хорошо известна и детально изучена традиционная постановка задачи оптимизации распределения
ресурсов. В ряде случаев, при определѐнных упрощениях, эта задача успешно
решается в постановке линейного и динамического программирования, а также
программирования в ограничениях (венгерский метод, симплекс метод и другие). При этом всегда предполагается, что имеется некоторая централизованная
система, в которую заранее оператором (диспетчером) введены все полученные
заказы и доступные ресурсы, определены их свойства, начальные позиции и состояния и т.д. Считается, что заказы и ресурсы жѐстко заданы изначально и не
меняются в ходе решения задачи.
В процессе своей работы система с помощью перебора рассматривает все
возможные варианты распределения ресурсов по заказам, ранжирует их и выбирает лучший вариант. Если в связи с большим объѐмом вычислений перебор
выполнить не удается, предлагается использовать различные эвристики или мета-эвристики, существенно сокращающие пространство решений и делающие
перебор более направленным (эвристика – это набор правил для выбора лучшей
альтернативы, метаэвристика – стратегия выбора эвристик).
В результате работы системы строится «близкое» к оптимальному расписание, после чего в заданный момент времени по команде оператора мобильные
ресурсы начинают двигаться по предписанным им планам и маршрутам движения, а возникающие «возмущения» либо игнорируются, либо полученные планы, по мере возможностей, корректируются вручную. При этом перебор вари­
­
­
­
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
антов немедленно приводит к высокой вычислительной сложности, и, следовательно, росту продолжительности построения планов.
Радикально новый подход к решению данной задачи позволяет осуществлять распределѐнное управление подвижными объектами, обладающими интеллектуальными способностями реагировать на события, динамически планировать свое поведение и добиваться реализации намеченных планов. Каждый
из участников при этом должен быть способен как к автономному принятию
решения по планированию собственного поведения, так и к согласованному
многостороннему взаимодействию с другими участниками и обладает для этого
необходимыми информационно-коммуникационными устройствами, помогающими постоянно находиться на связи «он-лайн» и принимать или согласовывать решения по ходу ситуации.
В качестве основы такого подхода выбран мультиагентный подход, активно развивающейся в последние годы на стыке работ по объектному программированию, параллельным системам, искусственному интеллекту и телекоммуникациям, который может применяться для решения сложных задач
управления ресурсами в реальном времени, обеспечивая большую открытость,
гибкость и оперативность, производительность и живучесть систем рассматриваемого класса. При этом вместо централизованного управления с выдачей команд «сверху-вниз» используются переговоры, построенные на принципах
взаимодействия равных партнеров, где при необходимости каждый может коммуницировать с каждым и структура такого взаимодействия не ограничена жесткими регламентами.
Однако наиболее сложной и актуальной является задача организации интерактивного взаимодействия операторов, диспетчеров, водителей и руководства компании по согласованному планированию ресурсов. Новые информационные технологии, обеспечивающие постоянную связь с помощью мобильных устройств (так называемых, «наладонников»), возможность задания индивидуальной логики принятия решений средствами онтологий, а также современные методы организации сопряженного взаимодействия представляют собой мощный инструментарий организации совместной деятельности пользователей по управлению мобильными ресурсами. Вместе с тем, решение этой задачи на практике требует дополнительных усилий по доработке пользовательского интерфейса и бизнес-процесса планирования, для того чтобы все возможности новых технологий стали доступны и удобны в использовании.
Кроме этого, весьма важно настроить логику агентов, правильно выбрав
цели и ограничения каждого агента, а также задав критерии оптимизации индивидуальных планов. Эти критерии могут быть разными даже в случае внедрения мультиагентной системы управления мобильными ресурсами в одной области: например, в двух разных транспортно-экспедиционных компаниях могут
использовать разные критерии, а существующие могут быть определены с разными приоритетами. Эта разница, в основном, определяется спецификой постоянных заказчиков и особенностями используемых ресурсов, составляющих
флот компании.
Данное пособие содержит сведения, необходимые для понимания основ
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
построения мультиагентных систем управления подвижными ресурсами в реальном времени и понимания механизма работы мультиагентных алгоритмов и
основных особенностей их применения. Пособие содержит теоретический материал и лабораторный практикум, для освоения которого необходимы начальные знания основ управления сложными системами и программирования, а
также базовые навыки построения мультиагентных систем управления подвижными объектами в реальном времени.
При проведении лабораторного практикума рекомендуется использовать
учебную версию мультиагентной системы управления транспортными ресурсами (краткое название – МАС УТР). Использование описываемой в данном
пособии мультиагентной технологии на примерах транспортной логистики
пользоволяет наглядно представить современные возможности по управлению
мобильными ресурсами в режиме реального времени.
Авторы выражают надежду, что представленный материал будет полезен
в изучении и дальнейшем применении мультиагентных технологий в задачах
управления различными ресурсами в реальном времени. Данное пособие может
быть рекомендовано как студентам вузов, так и инженерам, занимающимся
созданием и внедрением новых технологий планирования и управления динамическими ресурсами.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
1 МЕТОДЫ И АЛГОРИТМЫ ПЛАНИРОВАНИЯ РЕСУРСОВ
1.1 Современная постановка задачи управления мобильными
ресурсами в режиме реального времени
Задача управления мобильными ресурсами может быть сформулирована
следующим образом и проиллюстрирована Рисунок 1 [1-8]:
­ Имеется флотилия грузовиков (или других мобильных ресурсов), которые
могут иметь GPS / ГЛОНАСС датчики на борту;
­ В реальном времени поступают заказы (и другие события), которые необходимо распределять на ресурсы, учитывая текущие планы, индивидуальные
предпочтения и ограничения заказов и ресурсов;
­ Изменения должны вноситься в планы ресурсов без останова и перезапуска
системы, путем корректировки расписания с использованием свободных
окон, но также подвижками и переброской ранее распределенных заказов;
­ Должен быть реализован полный цикл управления:
­ реакция на события,
­ динамическое планирование,
­ исполнение планов;
­ Согласование планов должно осуществляться через сотовый телефон в ходе
диалога с водителем;
­ Необходимо вести мониторинг и контроль исполнения согласованных планов;
­ В случае расхождения плана и факта требуется перепланирование.
Система планирования и управления мобильными ресурсами должна
обеспечивать перечисленные ниже основные функциональные возможности:
Приѐм нового заказа. Может осуществляться как в ручном, так и в автоматическом режиме с использованием функции импорта из корпоративной
CRM системы. В сфере логистики все новые заказы обычно имеют стандартный набор полей, такие как: грузоотправитель и грузополучатель, тип и вес
груза, тип транспортного средства, грузоподъѐмность, адреса и время отгрузки
и доставки и другие. Заказы обычно принимаются оператором по телефону, через Интернет-портал или по электронной почте (например, от корпоративных
клиентов). В связи с этим для регистрации поступающих заказов вручную необходимо, чтобы у системы был дружественный интерфейс. Кроме того, в процессе приѐма заказов должны также учитываться различные категории и типы
клиентов. Например, у VIP клиентов могут быть дополнительные требования,
которые система должна обязательно принимать во внимание.
Автоматическое планирование новых заказов. Система старается подобрать наилучшее размещение заказа с учѐтом имеющихся в наличии ресурсов. При этом учитываются различные виды критериев, такие как: протяжѐнность маршрута, статус водителя (свободен, с заказом, скоро освободится и
др.), объективное распределение выгодных заказов между водителями и другие.
Если невозможно запланировать заказ автоматически, система позволяет сделать это в ручном режиме.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рис. 1
Рисунок 1 – Схема функционирования автоматизированной системы
управления мобильными ресурсами
Обратная связь с водителями. Водители используют специальные устройства, чтобы информировать систему о своѐм актуальном статусе и взаимодействовать с диспетчером при распределении новых заказов.
Трекинг. В системе управления мобильными ресурсами должна быть
возможность получения актуальной информации о местоположении и состоянии ресурсов компании и представления этих данных пользователю (оператору). При этом система должна позволять диспетчеру просматривать результаты
планирования, контролировать выполнение плана и, в случае необходимости,
вносить определѐнные изменения в план. В дополнение к этому, каждое новое
событие должно фиксироваться в системе и вызывать соответствующие изменения в расписании. Для этого используется специальный модуль оповещения
пользователя. В целях упрощения одно и то же расписание может использоваться для планирования и мониторинга. В таком случае процесс управления в
реальном времени рассматривается как утверждение соответствия расписания
текущей ситуации.
Ведение онтологии клиентов и ресурсов. Информация об имеющихся
ресурсах и клиентах представляется в виде базы знаний. При этом важно учи-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
тывать статистические данные и привязывать их к знаниям о заказах и ресурсах
(например, некоторым заказам требуются определѐнные типы ресурсов, некоторые ресурсы, в свою очередь, могут иметь ряд предпочтений в части поездок,
маршрутов и др.). Учѐт данных особенностей позволяет формировать гибкие и
эффективные методики ценообразования и управления компанией, а также
улучшить логику принятия решений агентами.
Карта бизнеса. Возможность формирования отчѐтных форм и представления данных об эффективности ведения бизнеса имеет огромное значение для
руководителей современных компаний, в связи с чем данная функциональность должна быть также включена в систему.
Интеграция. Взаимодействие с внешними информационными системами
также важно, поскольку в большинстве современных компаний уже используется определѐнный набор программных средств. В дополнение к ним целесообразно использование внешних геоинформационных систем, электронных карт
и call-центров.
1.2 Особенности планирования ресурсов в транспортнологистической компании
Ключевым этапом в общем процессе обработки заявок, поступающих в
транспортно-экспедиционную компанию, является поиск ресурсов для их выполнения.
Задачи транспортной логистики заключаются в сокращении сроков
транспортировки грузов и оптимизации затрат компании на всем пути движения грузов при максимально высоком уровне обслуживания посредников и конечных потребителей. В коммерческих транспортных организациях, где имеется распределенная структура с развитой филиальной сетью и используется
большое количество подвижного грузового транспорта, задача по автоматизации планирования поездок, управлению подвижными ресурсами, оптимизации
материальных и временных затрат на перевозку, контролю и учету операций
бизнес-процесса приема и исполнения заявок, а также повышению качества
оказываемых услуг в целом становится особенно актуальной с ростом числа
клиентов и заказов. Анализ технического оснащения современных транспортно-экспедиционных компаний показывает, что такие компании представляют
собой сложные объекты управления, которые характеризуются значительным
числом взаимозависимых ограничений и факторов, обусловленных технологическим регламентом и определяющих эффективность работы объекта управления, что вызывает определенные трудности при решении задачи планирования
выполнения заявки на транспортировку [1-8].
В процессе оказания услуги по транспортировке грузов задействовано три
стороны: заказчик (грузоотправитель), транспортно-логистическая компания
(ТЛК) и грузополучатель. Каждая из указанных сторон может иметь свои собственные, иногда противоречащие друг другу, цели. На Рисунок 2 показана упрощенная схема осуществления транспортировки груза, на которой представлены основные аспекты взаимодействия сторон, между которыми необходимо
обеспечить информационный обмен для эффективного управления процессом
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
транспортировки. Наличие некоторого центра, выполняющего функции диспетчера сквозного перевозочного процесса, осуществляющего единую функцию управления, дает возможность эффективно проектировать движение материальных и информационных потоков. Кроме того, качественное управление
возможно только при наличии системы поддержки принятия решений, которая
будет учитывать многокритериальность и неопределенность исходной информации, а также будет обеспечивать автоматизацию процесса поиска наилучших
вариантов. При автоматизации процесса управления транспортными ресурсами
необходимо учитывать такие факторы, как неравномерность поступления заявок на транспортировку и транспортных средств, возможные форс-мажорные
обстоятельства при выполнении заявки (например, поломка транспортного
средства), неравномерность загрузки транспортных средств, переменный уровень эксплуатационной надежности и т.п.
Рисунок 2 – Схема взаимодействия по обработке заявки
Можно выделить следующие задачи управления, решение которых имеет
определяющий характер для компаний, занимающихся оказанием транспортнологистических услуг:
­ организация процесса планирования ресурсов на выполнение заказа с учетом особенностей деятельности грузоотправителя/грузополучателя (напри-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
мер, режима работы складов и выходных);
­ обеспечение обратной связи с заказчиком (грузоотправителем) и двусторонней связи с водителем для получения актуальной информации о состоянии
выполнения заказа, а также возможных проблемных ситуациях.
При планировании с использованием автоматизированной системы
управления мобильными ресурсами необходимо учитывать следующие критерии:
­ Утилизация – отношение времени, потраченного на перемещение до места
загрузки и выполнение заявки, к общему рабочему времени в месяц. Необходимо, чтобы грузовики не простаивали и постоянно ездили по заявкам
(утилизацию надо постоянно повышать);
­ Абсолютная выручка – выручка, получаемая при выполнении заявки. Необходимо, чтобы выручка была максимальной (автоматизированная система
должна отдавать предпочтение заявкам с максимальной абсолютной выручкой).
­ Удельная выручка – выручка на километр. Система должна оценивать заявки по удельной выручке и сравнивать значение удельной выручки с некоторой граничной величиной. Среди заявок, с удельной выручкой, больше заданной границы, будет выбрана заявка с большей абсолютной выручкой
Среди заявок, приблизительно равных по абсолютной выручке необходимо выбирать те, у которых удельная выручка больше. Из двух заявок, удельная
выручка которых больше заданной границы, следует выбирать ту, которая выгоднее по абсолютной выручке. Если, согласно данным, указанным в заявке,
один грузовик вынужден будет совершить более протяженный переезд до точки погрузки, чем другой, следует выбрать грузовик, находящийся ближе с целью уменьшения количества «порожних» переездов.
Кроме этого, надо учитывать специальные правила: так как заявки из
крупного транспортного узла в другие города найти легче, необходимо планировать возврат в транспортный центр как можно быстрее, пусть и с меньшей
выручкой. При этом не стоит ждать, пока появятся более выгодные заявки или
выполнять заявки, требующие перемещения в другой город.
Одним из известных достоинств распространенных систем управления
транспортом являются развитые средства сценарного анализа «что если», которые позволяют по различным критериям проанализировать различные сценарии грузоперевозок и принять экономически обоснованное решение по лучшему из них. Но основное решение остается за менеджером, что не снимает субъективности логики принятия решения по каждому конкретному заказу.
1.3 Обзор алгоритмов распределения ресурсов
Существует множество алгоритмов, на основе которых строятся системы
распределения ресурсов. Рассмотрим наиболее известные из алгоритмов распределения ресурсов с учетом требований к системам распределения ресурсов
как к сложным системам.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
1.3.1 Списочные алгоритмы
Среди всех алгоритмов распределения ресурсов можно выделить достаточно простые для реализации алгоритмы, которые позволяют запланировать
заказ на необходимые ресурсы. К такому типу относятся списочные (приоритетные) алгоритмы [9]. Предположим, что несколько заказов ожидают планирования. В этом случае заказы выбираются из общего списка и поочередно отправляются на планирование. При планировании заказы выбирают ресурсы и
время выполнения либо по критерию наиболее раннего исполнения, либо в соответствии с другими критериями. Например, выбор рабочего делается на основе близости его разряда к необходимому, заданному в технологической операции. Заполняя постепенно свободное место операциями, списочный алгоритм
строит производственный план до достижения локального оптимума. Критерии
выбора из списка могут быть различные [9]. Например, задачи выбираются по
принципу очередности прихода в систему (First Come First Served – FCFS). Другим критерием может служить приоритет. Вначале планируются те заказы,
приоритет которых максимален в очереди (Highest Priority First – HPF).
Другой эвристикой для определения порядка планирования заказов может служить планирование, которое начинается с более коротких заказов по
направлению к более длинным с учетом заданных условий (необходимо запланировать максимальное количество заказов или максимально повысить утилизацию ресурсов). Задачи могут планироваться исходя из временных окон, в которые они должны быть выполнены. Так, первыми будут планироваться те заказы, у котороых максимально допустимое время исполнения минимально по
отношению к другим заказам из списка.
Наконец, может учитываться сложность планирования заказа: сложный
заказ, состоящий из множества подзаказов, связанных различными ограничениями, необходимо планировать раньше, так как более простые заказы имеют
большую степень свободы при планировании. Необходимо также упомянуть и
метод Монте-Карло, в соответствии с которым заказы выбираются из очереди в
случайном порядке. После планирования осуществляется оценка результирующего плана. Затем заново повторяются фазы планирования и оценки. Данные
операции повторяются до тех пор, пока качество плана не будет удовлетворительно, либо выполнится необходимое количество итераций, либо скорость
роста качества «лучшего» плана уменьшится до некоторой величины.
Некоторые из вышеприведенных алгоритмов используются также в системах реального времени при распределении задач по выполняющим их процессорам. Примеры использования данных алгоритмов можно найти в [10].
Списочные алгоритмы обладают рядом недостатков. В частности, алгоритмы подразумевают наличие очереди задач. В случае если очереди нет, алгоритм неприменим. Таким образом, системы, основой которых служат списочные алгоритмы, вынуждены работать только в батч-режимах. Чем больше размер батча, тем эффективнее работают рассматриваемые алгоритмы. Это приводит к тому, что все задачи объединяются в большие батчи и планируются за
пределы горизонта планирования, что приводит, как правило, к глобальным пе-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
рестройкам плана и низкой эффективности оперативного изменения плана в
случае непредвиденных обстоятельств. Таким образом, данный алгоритм обеспечивает достаточно низкую адаптивность.
1.3.2 Алгоритм имитации отжига
Алгоритм имитации отжига основывается на аналогии с термодинамическим процессом, который происходит при кристаллизации вещества из жидкого
состояния в твѐрдое. Изначально делается допущение, что атомы предварительно выстроились в кристаллическую решѐтку. В то же время часть атомов
может переходить из одной ячейки в другую. Данный переход осуществляется
с некоторой вероятностью. Температура постепенно понижается. Вероятность,
в свою очередь, также уменьшается с понижением температуры. Стабильная
кристаллическая решѐтка соответствует минимуму энергии атомов – «охлажденному состоянию». Изначально метод был предложен в 1982 году и описан в
[11]. В общем виде описание алгоритма можно найти в [17].
Данный подход нашел свое применение в системах распределения ресурсов. Для этого над планом определяются несколько операций, которые приводят к его изменению:
­ размещение заказа на ресурс (для полного размещения заказа, в зависимости
от необходимого числа ресурсов, может потребоваться несколько раз воспользоваться данной операцией);
­ обмен временем выполнения двух заказов;
­ замена ресурса у заказа на другой ресурс.
Случайно выбирается и осуществляется одна из указанных операций. В
зависимости от того, улучшился план или нет, данный шаг принимается сразу
или с некоторой вероятностью P(t) соответственно. Изначально вероятность
P(t) равна 1. С течением времени вероятность снижается, и переход к худшему
плану осуществляется все реже и реже. Таким образом, план все сильнее и
сильнее кристаллизуется.
К сожалению, у алгоритма имитации отжига существует следующий недостаток. Вследствие того, что он похож на метод наискорейшего спуска [14],
ему свойственно попадать в локальные минимумы и не выбираться оттуда [15].
1.3.3 Генетические алгоритмы
В настоящее время одними из самых популярных алгоритмов многоэкстремальной оптимизации являются генетические алгоритмы (ГА). Данные алгоритмы основываются на принципах теории эволюции и опыта селекции растений и животных [18]. Идея поиска оптимального решения в генетических алгоритмах заключается в следующей гипотезе: чем выше приспособленность
особи, тем выше вероятность того, что у потомков, полученных с еѐ участием,
признаки, определяющие приспособленность, будут выражены ещѐ сильнее
[19]. Генетические алгоритмы являются подмножеством эвристических алгоритмов поиска.
В n-мерном пространстве задается функция f x1, x2 ,..., xn , которая называется функцией качества, а также приспособляемостью особи. В процессе рабо-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ты алгоритма выполняется поиск максимума данной функции. Выбираются несколько точек из рассматриваемого n-мерного пространства:
X1 x11, x12 ,..., x1n , X 2 x21 , x22 ,..., x2n , …, X m xm1, xm2 ,..., xmn .
Данные точки называются особями или хромосомами. Координаты самих
точек ( x1 , x2 ,..., xn ) – генами в хромосоме. Выбранные особи составляют начальную популяцию. При работе генетического алгоритма используются две операции, с помощью которых получают популяцию следующей итерации: скрещивание и мутация.
С помощью данных операций из предыдущей популяции появляется новая временная популяция Pn, причем количество особей в полученной популяции больше, чем в исходной. Из полученной популяции удаляются те особи, у
которых значение функции приспособленности наименьшее. Однако решение о
том, какие особи удалять, не является жестко детерминированным. Удаление
происходит с учетом некоторой вероятности, которая зависит от значения самой функции приспособленности. Таким образом, в полученной популяции
окажутся не только особи с наибольшей функцией приспособленности.
Рассмотрим более подробно операцию скрещивания. Данная операция
обеспечивает обмен генетическим материалом. Новый потомок, появляющийся
с помощью указанной операции, может получить лучшие положительные качества своих родителей. В результате значение функции приспособленности для
новой особи будет лучше, чем у исходных родителей. Операция скрещивания
заключается в следующем. Берутся две произвольные особи. Случайно выбирается целое число k, значение которого удовлетворяет неравенству 1 k n . У
обеих особей первые k генов остаются на месте, затем особи обмениваются между собой оставшимися частями хромосом. С помощью данного механизма получаются две новые особи. Необходимо отметить, что родители также остаются
в новой популяции. Так как операция скрещивания рождает новые особи обменом группами генов, принципиально новых особей не рождается. В этом случае
алгоритм может легко скатиться в локальный экстремум. Для того чтобы избежать этого, вводится операция мутации.
Операция мутации добавляет в новую популяцию некоторое количество
случайных хромосом. Иногда небольшое изменение лишь одного или нескольких генов в хромосоме приводит к значительному улучшению функции качества для полученной особи.
В системах распределения ресурсов каждому гену ставится в соответствие пара (ресурс, время), которая соответствует состоянию заказа в плане.
Функция приспособленности определяется как количество запланированных
заказов, суммарная утилизация ресурсов или других ключевых показателей эффективности. Может производиться также и минимизация использованных ресурсов. Операция скрещивания, описанная ранее, остается практически без изменений. Операция же мутации изменяет в гене либо ресурс, либо время, либо
и то и другое одновременно.
Особенностью генетического алгоритма является нахождение глобального экстремума в вероятностном смысле. Вероятность нахождения экстремума
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
зависит от размера популяции. С другой стороны, ни один из операторов не использует знание локального рельефа функции приспособленности. Таким образом, процесс генерации носит стохастический характер, и нет никаких гарантий, что будут сгенерированы особи с более подходящим значением функции
приспособленности. В результате в процессе эволюции получается достаточно
большое количество «неудачных» особей, что, в свою очередь, увеличивает количество обращений к функции качества. Это приводит к увеличению времени
поиска глобального экстремума. Генетические алгоритмы осуществляют поиск
оптимального решения только внутри заданного диапазона. Данная особенность приводит к необходимости задавать как сами диапазоны, так и число
хромосом с большим запасом, что отрицательно сказывается на времени поиска.
1.3.4 Мультиагентный подход
Агентом считается все, что действует (слово агент произошло от латинского слова agere – действовать) [33,34]. Но предполагается, что компьютерные
агенты обладают некоторыми другими атрибутами, которые отличают их от
обычных «программ», такими как способность функционировать под автономным управлением, воспринимать свою среду, существовать в течение продолжительного периода времени, адаптироваться к изменениям и обладать способностью взять на себя достижение целей, поставленных другими. У агента задаются предпочтения, которые соответствуют предпочтениям пользователя.
Агент начинает действовать от лица пользователя. Изначально, а также во многих современных системах, агенты используются для решения различных рутинных задач. В этом случае агенты представляют собой небольшие программы, которым можно назначать задания и указывать различные предпочтения и
ограничения. Некоторые агенты имеет способность про-активно выходить на
пользователя. Например, многие антивирусные программы умеют при обнаружении сомнительных действий, которые могут привести к повреждению или
модификации данных, выйти в диалог к пользователю и предложить варианты
действий, которые необходимо предпринять в сложившейся ситуации.
Идея использования программных агентов оказалась настолько удачной,
что получила свое развитие. Качественный переход произошел в следующем
направлении: агент может не только общаться с пользователем, интересы которого он представляет, но и с другими агентами, которые могут представлять
интересы других пользователей или, в общем случае, произвольных сущностей.
Предпочтения одного агента могут конфликтовать с предпочтениями другого
агента. В этом случае необходимо разрешить конфликт. Для этого агенты с помощью переговоров пытаются выработать компромиссный вариант, который
бы удовлетворил обоих. Например, для заказа, чем меньше стоимость его выполнения, тем лучше. Для выполняющего данный заказ ресурса, напротив,
лучше, когда стоимость выше. Налицо типичный конфликт интересов. На практике данный конфликт решается взаимными уступками по стоимости. В итоге
обе стороны сойдутся на одной стоимости, и конфликт будет исчерпан.
Так появились мультиагентые системы, в которых задаются агент пред-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
приятия, агенты заказов, агенты ресурсов. Это первый шаг от централизованного планирования к более распределенному. Распределенное планирование обладает большей гибкостью в том смысле, что планирование осуществляется не
перестройкой всего плана, а локально, изменением только тех частей плана, которые действительно необходимо модифицировать. Данное свойство непосредственно следует из того, что агенты по своей сути изменяют только свой индивидуальный план.
Другим важным свойством, являющимся следствием распределенного
планирования, можно назвать адаптивность. Построение локальных изменений
производится не по жесткому централизованному алгоритму, а является результатом совместной работы отдельных агентов, учитывающих свои состояния и действующих по обстоятельствам.
В [33] приводятся определения агента в «слабом» и «сильном» смыслах.
Под интеллектуальным агентом (ИА) в слабом смысле понимается программно
или аппаратно реализованная система, которая обладает такими свойствами:
­ автономность – способность ИА функционировать без вмешательства человека и при этом осуществлять самоконтроль над своими действиями и внутренним состоянием;
­ общественное поведение (social ability) – способность функционировать в
сообществе с другими агентами, обмениваясь с ними сообщениями с помощью некоторого общепонятного языка коммуникаций;
­ реактивность (reactivity) – способность воспринимать состояние среды и
своевременно отвечать (реагировать) на те изменения, которые в ней происходят;
­ про-активность (pro-activity) - способность агента брать на себя инициативу,
т.е. способность генерировать цели и действовать рационально для их достижения, а не только реагировать на внешние события.
Сильное определение агента предполагает, что у агента имеется ряд
свойств, дополняющих перечисленные выше. В частности, главным из них является наличие у агента хотя бы некоторого подмножества так называемых
«ментальных» свойств, называемых также интенсиональными понятиями, к которым относятся следующие:
­ знания (knowledge) – это постоянная часть знаний агента о себе, среде и других агентах, т.е. та часть, которая не изменяется в процессе его функционирования;
­ убеждения (beliefs) – знания агента о среде, в частности, о других агентах;
это те знания, которые могут изменяться во времени и становиться неверными, однако агент может не иметь об этом информации и продолжать оставаться в убеждении, что на них можно основывать свои выводы;
­ желания (desires) – это состояния, ситуации, достижение которых по разным
причинам является для агента желательным, однако они могут быть противоречивыми и потому агент не ожидает, что все они будут достигнуты;
­ намерения (intentions) – это то, что агент или обязан сделать в силу своих
обязательств по отношению к другим агентам (ему «это» поручено и он взял
эту задачу на себя), или то, что вытекает из его желаний (т.е. непротиворе-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
чивое подмножество желаний, выбранных по тем или иным причинам, совместимых с принятыми на себя обязательствами);
­ цели (goals) – конкретное множество конечных и промежуточных состояний,
достижение которые агент принял в качестве текущей стратегии поведения;
­ обязательства по отношению к другим агентам (commitments) – задачи, которые агент берет на себя по просьбе (поручению) других агентов в рамках
кооперативных целей или целей отдельных агентов в рамках сотрудничества.
Применительно к планированию для каждой задачи и ресурсов, на которые должны быть запланированы задачи, назначаются агенты. И для агентов
задач, и для агентов ресурсов задаются предпочтения. Целью агентов заказов и
ресурсов является построение плана в соответствии с определенными критериями. При запуске мультиагентной системы планирования агенты, основываясь на своих целях и предпочтениях, строят план, находя различные компромиссы. Описание различных мультиагентных систем можно найти в работах
[33-34, 67].
1.3.5 Сравнительный анализ алгоритмов распределения ресурсов
В Таблица 1 представлены результаты сравнительного анализа известных
алгоритмов распределения ресурсов.
Таблица 1 – Сравнительный анализ алгоритмов распределения ресурсов
АлгоГенеМульСпиНейритм
тичеСимтиасочные
CPM и
ронКритерии
имиские
плекс
генталгоPERT
ные
тации
алгометод
ный
ритмы
сети
отжига ритмы
подход
–
–
Посто–
+
+
+
С обратной
янная
связью
оценка
генерируемых
особей
Воз–
Про–
Реко+
Оператив- Практи
чески можно,
стой
менданое планинеосу- однако
переции
рование
счет
(приход со- щест- требует
вимо
дополсроков
бытий ненительвыполдоступноных сонения
сти ресургласо
главса, нового
ной зазаказа, отваний
дачи
мена закапланов
за)
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Критерии
Возможность
планирования не в
батчрежиме
Локальные
изменения
плана
Направленный
поиск
Адаптивность к изменениям
предметной области
Возмож-
Списочные
алгоритмы
АлгоГенеритм
тичеимиские
тации
алгоотжига ритмы
Симплекс
метод
Нейронные
сети
Мультиагентный
подход
Малоэффективно
Малоэффективно
Тольконе в
батчрежиме
–
+
+
Только СпонГлоЛокаль
не в
танные
баль
ные
батч- измене
ные
режиме ния в
произвольных
участках
плана
Такти- Направ Направ Направ
чески ленный
ленленный
направ- стохас- ность
критиленный тичеобес- ческим
ский
печипутем.
(+)
вается Скорее
отбо–, чем
ром
+
особей
(+/–)
–
Неопределяемо
+
+
–
+
–
Легко
Легко
–
Пере-
+
–
Сложно
Сложно
Очень
сложно
–
+
–
CPM и
PERT
Изменения
на основе
пересчета
вероятностей.
Достаточно
просто
+
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Критерии
ность подхвата изменений в
предметной области в состоянии
уже составленного плана
Детерминированный/ стохастический/ самоорганизация
Возможность проактивного
выхода на
пользователя с
предложениями по
улучшению небольших
участков
плана
Направленность
Списочные
алгоритмы
АлгоГенеритм
тичеимиские
тации
алгоотжига ритмы
CPM и
PERT
Симплекс
метод
Нейронные
сети
Мультиагентный
подход
обучение сети
Полностью
детерминированный
ДетерЭвоминилюцирован- онный,
ное по- осностроеван
ние с
ный на
неболь итерашим
тив
учетом
ном
стохаст улучше
ики
нии
особей
Детерминированный
Детерми
нирован
ный
Детер
минированный
–
–
–
+
–
–
+
Ориентация
Ориентация
+
Использу-
–
Квазидетерминированный,
эволюционнность,
основанная
на итеративном
улучшении
+
Ориентация
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Критерии
Списочные
алгоритмы
на решение
задач планирования
ресурсов
Поиск глобального
экстремума
–
АлгоГенеритм
тичеимиские
тации
алгоотжига ритмы
на ши- на широкий
рокий
спектр спектр
задач
задач
(+/–)
(+/–)
–
–
CPM и
PERT
+
Симплекс
метод
ется
для малокритериальных задач
–
Нейронные
сети
–
Мультиагентный
подход
на построение
связей
заказ/рес
урс
–
Ниже приведены краткие описания известных эвристик и метаэвристик
[47-51]:
­ «жадные» методы, в которых решения принимаются последовательно путем
выбора на каждом шаге лучшей из альтернатив, при этом однажды принятое
решение никогда не пересматривается. Более сложными являются специализированные методы локальной оптимизации, где некоторое начальное приближение улучшается различными локальными изменениями. Если хорошее
решение не достигнуто, может генерироваться некоторое новое начальное
приближение и процесс повторяется.
­ Simple Local Search Based Meta-heuristics (SLSBM) – мета-эвристики локальной оптимизации со случайным выбором кандидата из списка лучших, с
прогнозированием и случайным выбором критериев.
­ Simulated Annealing (моделирование процесса остывания) – расширение методов локальной оптимизации, в котором формируются зависимые решения,
причем на каждом шаге решения могут не только улучшаться, но и ухудшаться с вероятностью, вычисляемой как функция от некоторого управляющего параметра, аналога температуры.
­ Tabu Search – метод, использующий историю методов локальной оптимизации, когда некоторые уже исследованные варианты запрещается использовать на следующих шагах (табу).
­ Ant Search – метод, моделирующий поведение муравьев, добывающих пищу.
Некоторое удачное решение уподобляется помечаемому ферромоном направлению перемещения муравьев к корму, интенсивность «запаха» которого уменьшается, если со временем это решение не улучшается.
­ Adaptive Memory Programming – использование общей памяти решений.
­ смешанные мета-эвристики Miscellaneous – использование нескольких параллельных алгоритмов, каждый из которых формирует свое решение.
Вместе с тем, даже с учетом рассмотренных мета-эвристик, применяемые
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
методы и средства перебора вариантов работают в пакетном режиме, требуют
больших затрат времени на расчет планов и не могут применяться для адаптивной корректировки планов в реальном времени по мере поступления новых событий.
Поэтому и требуется радикально новый подход к решению данной задачи, в котором осуществляется коллективное распределѐнное управление подвижными объектами, обладающими интеллектуальными способностями реагировать на события, динамически планировать свое поведение и добиваться реализации намеченных планов. Каждый из участников при этом должен быть
способен как к автономному принятию решения по планированию собственного поведения, так и согласованному многостороннему взаимодействию с другими участниками и обладает для этого необходимыми информационнокоммуникационными устройствами, помогающим постоянно находится на связи «он-лайн» и принимать или согласовывать решения по ходу ситуации.
Основной задачей мультиагентной системы в рассматриваемой области
является построение и поддержание баланса интересов заказчиков, самой компании, водителей и других участников процесса принятия решений. При этом
каждый участник взаимодействия может иметь свои потребности и возможности, реализуемые через роли заказов и ресурсов участников, постоянно стремящихся найти друг друга и установить связи между собой, бронируя ресурсы
под заказы.
Мультиагентная система не только позволяет моделировать сценарные
варианты «что будет, если…», но и «подсказывать» пользователю действительно оптимальные варианты планирования транспортных ресурсов, а для большей части заказов производить планирование в автоматическом режиме, что
приводит к повышению объективности принимаемых решений. Другим важным преимуществом мультиагентной системы является возможность реагировать на появляющиеся в реальном времени нештатные или чрезвычайные ситуации (например, при поломке транспортного средства или задержке при выполнении заявки, происходит автоматическое перепланирование всего расписания), в то время как классические системы данного направления лишь позволяет оценить неблагоприятность той или иной ситуации.
Основные отличия выбранного решения, основанного на использовании
мультиагентных технологий, от существующих подходов по разработке и внедрению систем управления транспортом состоят в следующем. Функциональность этих систем учетной направленности заключается в оперативной выдаче
сведений о местонахождении груза и сроках его доставки по запросу менеджера. При решении задача подбора «оптимального» ресурса для выполнения каждой заявки традиционные системы не могут учесть всех реально существующих
параметров и требований, которые налагают на них грузоотправители, грузополучатели, особенностей загрузки транспортных средств и реальной пропускной
способности дорог. По мере возрастания числа бизнес ограничений (график работы объектов, характеристики транспортных средств, маршрутов и т.д.)
уменьшается наглядность и прозрачность схемы взаимодействия, и, как следствие, выбор оптимального решения становится крайне сложным.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
2 МУЛЬТИАГЕНТНАЯ МОДЕЛЬ АДАПТИВНОГО
ПЛАНИРОВАНИЯ МОБИЛЬНЫХ РЕСУРСОВ
2.1 Метод адаптивного планирования
С учетом описанных бизнес-процессов управления мобильными ресурсами (Рисунок 3) целесообразно использование метода адаптивного планирования, который позволит добиться следующих преимуществ [37, 42]:
­ обеспечение индивидуального подхода к выполнению каждого заказа;
­ автоматизация основных операций операторов по планированию ресурсов;
­ накопление знаний о специфике бизнеса, позволяющих уточнять и совершенствовать правила принятия решений при планировании;
­ повышение оперативности принятия решений и сокращение времени планирования;
­ осуществление эффективного наглядного оперативного управления имеющимися заказами, повышение операционной эффективности;
­ своевременное извещение операторов о возможных проблемах (отсутствие
заказов на будущее, расхождение между «планом» и «фактом», неэффективное использование транспортных средств и т.д.);
­ получение соответствующей комплексной систематизированной отчетности,
снижение издержек по составлению и систематизации отчетной документации.
­
Метод адаптивного планирования основан на использовании концепции
сети потребностей и возможностей, метода сопряженных взаимодействий и метода компенсаций.
2.1.1 Сеть потребностей и возможностей
При этом в качестве базовых классов мира агентов для распределения ресурсов были выбраны агенты потребностей и возможностей, по определению представляющих собой сущности с противоположными интересами, постоянно конкурирующих и кооперирующих на виртуальном рынке. На Рисунок
4 показана сцена виртуального рынка: поиск агентов потребностей (белые) и
возможностей (серые), показан различный уровень удовлетворенности связями
и разные виды связей (предварительное бронирование и т.д.).
Роль потребности несет в себе знание «идеала» (будущего), а роль возможности – знание «реальности» (прошлого). Так, каждый грузовик в мультиагентной системе управления перевозками знает, каков был его маршрут, где
сейчас он находится, каким грузом он загружен и т.д. Получая предложения от
разных грузовиков, заказ может решить, какой из них ему лучше всего подходит. Но, с другой стороны, и сам грузовик может породить новую «потребность», специфицируя какие именно заказы ему нужны в текущий момент времени, чтобы быть полностью загруженным.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 3 – Бизнес-процессы управления мобильными ресурсами
Сеть потребностей и возможностей (ПВ-сеть) [54] формируется программными агентами потребностей и возможностей ее элементов, в частности,
заказов и ресурсов, постоянно стремящихся найти друг друга и установить связи. Например, для компании грузовых перевозок модель ПВ-сети может включать агентов клиента и заказа, грузовика и груза, маршрута поездки, магазина и
склада, водителя и т.д. При этом заказ постоянно ищет себе лучший грузовик, а
грузовик встречно – заказ, но также маршрут и водителя и т.п. Сложность модели ПВ-сети и точность моделирования реальной транспортной сети могут наращиваться как с ростом числа программных агентов, представляющих интересы различных физических и абстрактных сущностей, необходимых для работы
каждой сети, так и с ростом типов и вариантов взаимодействий между агентами
разных классов.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 4 – Сцена виртуального рынка
Мультиагентный подход к решению задачи динамического планирования
и управления мобильными ресурсами основан на использовании концепции
динамической сети программных агентов потребностей и возможностей (ПВсети), в которой выделяются агенты (роли) потребностей и возможностей, по
определению представляющих собой сущности с противоположными интересами, которые действуют в рамках виртуального рынка системы на основе экономических рассуждений и могут как конкурировать, так и кооперироваться
друг с другом. В такой сети могут быть представлены конкретные заказы на
доставку грузов и конкретные ресурсы (например, водители, транспортные
средства, склады и т.п.).
Главной задачей такой системы является построение и поддержание баланса интересов всех участников производственного процесса. Для такого рода
систем становится характерным переход от централизованных решений к распределенным; замена иерархий на сетевую организацию, команд-инструкций
«сверху-вниз» – на переговоры равноправных сторон, жестких планов – на гибкие планы, фиксированных цен – на договорные и т.д. В условиях современной
экономики эти принципы обеспечивают более высокую гибкость и эффективность управленческих решений.
В ходе процесса переговоров агентов производится построение квазиоптимального, сбалансированного по многим критериям плана перевозок с учетом индивидуальных ограничений и предпочтений, а также целей транспортнологистической компании в целом. В случае возникновения непредвиденных событий (поломка грузовика, опоздание водителя, погодных условий), агенты могут динамически, в режиме реального времени, перераспределить задания на
другие доступные ресурсы, без пересмотра всего плана перевозок.
Агенты потребностей и возможностей взаимодействуют следующим образом. Заказы и ресурсы могут вступать в непосредственные связи между собой
и инициировать процесс взаимного пересмотра и согласования планов по мере
возникновения ожидаемых или заранее непредвиденных событий с каждым из
этих элементов (новый более выгодный заказ, отзыв уже принятого заказа, новый грузовик, поломка грузовика и т.д.). За счет такой динамической сетевой
организации разрабатываемая система в любой момент времени может пересматривать связи между этими элементами и согласованно менять их планы.
Таким образом, обеспечивается автоматическое гибкое планирование ресурсов
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ТЛК в реальном времени, как в автоматическом режиме, так и в диалоге с человеком.
Для реализации мультиагентного подхода к рассматриваемой задаче разработан метод сопряженных взаимодействий, который позволяет каждому участнику взаимодействий создавать свои планы в виде гибко формируемых сетей
связанных операций и согласовывать эти планы с другими участниками или по
мере возникновения любого рода непредвиденных событий, таких как изменение приоритетов в решении задач, появление новых задач, задержек, отказов
ресурсов и т.д.
В основе метода лежит принцип совместной заинтересованности всех
участников в решениях, выгодных как для каждого из них, так и для системы в
целом. При этом ухудшение положения одного из участников группы, в интересах группы, может ему компенсироваться группой за счет выигрыша для
группы в целом.
Реализация метода сопряженных взаимодействий подвижных объектов,
позволяющего управлять группой мобильных ресурсов в режиме реального
времени, базируется на основе сочетания технологий семантического веба для
представления знаний, необходимых для принятия согласованных решений в
ходе планирования, и мультиагентной технологий. Основой взаимодействия
всех указанных агентов становится общий виртуальный рынок, на котором
агенты могут покупать или продавать свои сервисы, исходя из экономической
целесообразности.
Правила принятия решений агентами на виртуальном рынке определяются моделью микроэкономики ПВ-сети, определяющей стоимости таких сервисов, систему штрафов и бонусов, как агенты делят прибыль, какие налоги и при
каких действиях должны платить и т.п. Все это призвано дать агентам возможность накапливать виртуальные деньги, играющие роль энергии в системе, и
использовать их для формирования новых или поддержания существующих
связей.
При этом принятие решений несколькими агентами и установление связей между ними для решения задач, непрерывно возникающих при поступлении каждого нового события, вызывает изменение условий функционирования
для других агентов и тем самым определяет процесс самоорганизации системы,
приводящей к перестройке расписания в ответ на события.
Таким образом, суть метода сопряженных взаимодействий заключается в следующем [52, 53].
1. Фиксируется множество сопряженных (в общем случае, неоднородных) элементов системы, каждый из которых обладает определенными ресурсами и
потребностями в других ресурсах.
2. Описываются индивидуальные цели и критерии принятия решения всеми
элементами системы, а также их предпочтения и ограничения.
3. Определяются правила и протоколы (регламенты) сопряженных взаимодействий между элементами, позволяющие выявлять конфликты и находить
компромиссы между элементами.
4. С помощью специальных инструментальных средств программирования
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
разрабатывается программа моделирования сопряженных взаимодействий.
5. С помощью этой программы строится первоначальная ПВ-сеть, определяющая соответствующее распределение ресурсов.
6. Если состояние ресурсов или потребности в них изменяются с приходом новых событий, то ПВ-сеть перестраивается с целью разрешения конфликтов,
причем в той части, которая непосредственно связана с изменениями (в предельном случае – вся сеть).
7. Решение задачи распределения ресурсов считается найденным, когда ни
один элемент ПВ-сети не может улучшить свое состояние в сети.
Таким образом, ПВ-сеть заказов и ресурсов отражает постоянно изменяющееся и никогда не останавливающееся («живое») расписание, являя собой
пример самоорганизующейся системы, адаптирующей свое поведение под действием событий, происходящих в реальном времени.
Знания, на основе которых агенты принимают решения, могут быть отделены от программного кода и храниться в онтологии системы, что обеспечивается с помощью специального инструментария поддержки онтологий и сцен,
отраженных в архитектуре системы (Рисунок 5).
Конкретная ситуация, складывающаяся с ресурсами, описывается в виде
сцены, связывающей конкретные экземпляры объектов (название компании
клиента, имя водителя грузовика, номер транспортного средства и т.п.).
Интерфейс пользователя
Онтологии
организации
(знания)
Виртуальный мир агентов Прикладные
компоненты
организации
Сцены
организации
(ситуации)
Сцена мира
Интеграция с
внешними программами
Исполняющая система
Рисунок 5 – Общая структура мультиагентной системы распределения ресурсов
Постоянная активность всех агентов сети, причем как со стороны потребностей, так и возможностей, вызывает многосторонние переговоры на виртуальном рынке, идущие квазипараллельно. При этом особенностью подхода является тот факт, что каждый агент рассматривается как машина состояний, возвращающая управление диспетчеру после каждого такта переговоров. Каждый
агент постоянно старается добиться своей цели и для этого вступает в отношения (связи) с другими агентами (заказ бронируется на грузовик, грузовик – на
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
водителя и т.д.), устанавливаемые в сцене, которые могут пересматриваться
агентами в результате выявления и разрешения конфликтов под действием
приходящих извне или генерируемых внутри системы событий.
При этом конфликты, порождаемые событиями (например, отказ грузовика), могут разрешаться агентами заказов и ресурсов путем переговоров и взаимных уступок, направленных на достижение приемлемых для всех компромиссов. Компромисс достигается тогда, когда один агент уступает свое место
другому, причем с ухудшением своего положения, что сопровождается выигрышем для всей системы или второго агента и соответствующим образом компенсируется из запаса виртуальных денег. Разрешение конфликта может вызывать целую цепочку операций перепланирования (включая переход заказов на
другой ресурс, сдвижку заказов вправо или влево по шкале времени на ресурсе,
обмен заказами между ресурсами и т.д.), глубина которой может быть ограничена допустимым временем ответа или другими факторами. В то же время, если
имеется запас времени, решение о выделении ресурса или сформированное
расписание использования ресурса может подвергаться непрерывной, в том
числе, и классической оптимизации, или, в общем случае, балансировке интересов всех участников, поскольку, как уже было отмечено выше, каждый заказ
или ресурс может иметь собственную специфическую систему критериев,
предпочтений и ограничений.
Так, при поступлении нового заказа в систему создается его агент, который от лица этого заказа вступает во взаимодействие с агентами ресурсов для
поиска лучшего своего размещения. Если наиболее подходящие ресурсы уже
заняты, они могут начать предлагать размещенным на них ранее заказам поискать себе новые размещения. Этот процесс, как цепная реакция, может захватывать все новые заказы и ресурсы, формируя расходящуюся волну изменений.
Если же вдруг, по каким-то причинам, выбранный грузовик позже становится недоступен (поломка, авария и т.д.), то его агент должен найти все заказы, которые сейчас планируются на размещение в этом грузовике и сообщить
им о недоступности ресурса. Эти заказы активируются и начинают искать себе
другие грузовики, что позволяет оперативно, гибко и надежно перепланировать
маршруты поездок. Результат считается достигнутым и система завершает
свою работу в том случае, когда ни у одного агента нет больше возможностей
улучшить свое состояние.
Важные особенности разработанного подхода связаны с конструкциями
применяемых агентов и протоколами их взаимодействий, допускающими указанный выше пересмотр принятых ранее решений в ходе работы системы, что и
обеспечивает возможность работы системы в реальном времени.
2.1.2 Метод компенсаций
Для реализации рассмотренного подхода предлагаются специально разработанные методы и средства, реализующие различные варианты ПВ-сетей.
При этом в разработанном методе компенсаций [52] перебронирование
ресурсов осуществляется лишь только в том случае, если входной заказ оплачивает ранее распределенным заказам ухудшение их положения, что осуществ-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ляется соответствующей «волной» переговоров (Рисунок 6 - Рисунок 8).
Заказ 1
1,2
Ресурс 1
Ресурс 2
3,4,5
Рисунок 6 – Обнаружение заказом двух ресурсов и бронирование второго
ресурса для реализации заказа: 1 – запрос к первому ресурсу, 2 – ответ и
предложение от первого ресурса, 3 – запрос второму ресурсу, 4 – ответ и
предложение от второго ресурса, 5 – выбор варианта второго ресурса и его
бронирование
Заказ 1
8,9
Ресурс 2
7,10
Заказ 2
Ресурс 1
6, 11
Рисунок 7 – Приход второго заказа и перебронирование второго ресурса
для второго заказа с выплатой компенсации: 6 – запрос ко второму ресурсу, 7 – переадресация предложения первому заказу от второго ресурса, 8 –
запрос к первому ресурсу, 9 – положительный ответ и предложение, 10 разрешение на перебронирование второго ресурса, 11 – согласие и предложение с суммой компенсации первому заказу
Заказ 1
12,13,14
15
Ресурс 1
Ресурс 2
Рисунок 8 – Освобождение ресурса также вызывает пересмотр ситуации и
перепланирование ресурсов даже «на лету», в ходе исполнения заказа: 12 –
освободившийся ресурс инициирует выполняющийся заказ, 13 – выясняется, что перегрузка на второй ресурс выгодна для первого заказа, 14 – дается подтверждение и бронирование второго ресурса, 15 – первому ресурсу
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
дается извещение об изменении маршрута и необходимости перегрузки
груза на второй ресурс
Здесь в примере из транспортной логистики для упрощения намеренно
опущены все детали и дана лишь самая общая схема (модель) взаимодействия
некоторых заказов и ресурсов как примеров потребностей и возможностей, но
данная схема применима к заказам и маршрутам, грузовикам и водителям, поездкам и заправкам топливом и т.д.
Таким образом, решение задачи при данном подходе формируется эволюционным образом, в ходе отработки каждого нового события, и потому является необратимым (для обратимости необходимо воспроизведение условий,
при которых решение принималось). При этом формирующееся расписание
рассматривается не как «статическая» структура данных, полученная в результате однократного применения некоторого монолитного алгоритма, имеющая
жестко фиксированные связи, а как неустойчивое динамическое равновесие
(или «устойчивое неравновесие»), получаемое и поддерживаемое путем взаимодействия двух противоположных сущностей «потребностей» и «возможностей», играющих роли взаимосопряженных понятий подобных «инь» и «ян».
Следует отметить, что чем выше удовлетворенность потребностью или
возможностью, тем сильнее связи между элементами расписания (порядок в
системе), и тем труднее его будет изменить в будущем. И, наоборот, чем менее
удовлетворены агенты своими состояниями, и чем активнее они продолжают
искать альтернативные варианты, тем ближе система к состоянию хаоса, но и
тем гибче может перестраиваться расписание.
При этом даже самый небольшой заказ, при определенных условиях, может повлечь за собой кардинальную структурную перестройку всего расписания, когда малые изменения на входе системы породят непредсказуемо большие изменения на выходе. Такие процессы самоорганизации должны позволять
наблюдать в системе и ряд других феноменов сложных динамических систем,
такие как «осцилляции», «катастрофы» и т.п.
Разработанный подход во многом интегрирует многие современные идеи
оптимального планирования, реализуемого в мета-эвристиках, создавая среду
конкурирующих и кооперирующих алгоритмов (агентов). Так, агенты могут запоминать и избегать плохих решений за счет использования своей памяти, информировать друг друга о промежуточных опциях, при близости опций принимать решения случайно, прекращать поиск при наличии ограничений по времени принятия решений и т.д.
За счет представления задачи в форме, близкой к естественной, логика
принятия решений системы становится более прозрачной как для программистов, так и для операторов, что позволяет встраивать большее число эвристик
без увеличения сложности кода и уменьшает общее время разработки системы,
а также делает результаты системы удобными для работы пользователей.
Для реализации мультиагентного подхода к управлению планированием
подвижных объектов необходимо разработать архитектуру мультиагентной
системы в виде множества работающих асинхронно (квазипараллельно) сопрограмм, представляющих собой «легких» агентов, использующих онтологию
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
для представления знаний предметной области и общую память объектов данных (сцену), отражающих текущую ситуацию во внешней среде, а также формирующих сети связей в ходе прямых переговоров.
2.2 Обзор архитектуры мультиагентных систем
В основе мультиагентной технологии лежит понятие «агента» – программного объекта, способного воспринимать ситуацию, принимать решения и
коммуницировать с себе подобными, динамически устанавливая связи между
собой.
В работах [38, 67] рассмотрена классификация агентов, в которой выделены три основных типа агентов:
­ Реактивные агенты. Термин реактивные агенты впервые возник в работах
Брукса [39]. Реактивные агенты не имеют какой-либо символьной внутренней модели мира и работают по правилам типа ситуация-действие, выбирая
из них действия, наиболее подходящие к конкретной ситуации. Эти агенты
просты по конструкции и сравнительно неплохо приспособлены к работе в
оперативном режиме (режиме, близком к режиму реального времени).
­ Мыслящие агенты (делиберативные). Агенты данного типа обладают внутренним представлением о мире, которое меняется в процессе размышления
агента. Как правило, строится модель размышлений (поведения) агента (например, BDI модель).
­ Смешанные типы агентов. К недостаткам реактивных агентов можно отнести трудность в реализации целеустремлѐнных агентов. Мыслящие агенты,
основанные на общих механизмах рассуждений, являются недостаточно
гибкими и слишком медленно реагируют на внешние события. С целью устранения этой проблемы была введена и описана идея многоуровневой архитектуры агента (агенты смешанного типа). Такая архитектура агента заключается в разбиении функциональности агента на несколько уровней, при
этом каждый уровень работает и взаимодействует с другими на основе иерархии.
Мультиагентная система – это сеть слабо связанных решателей частных
проблем (агентов), которые вместе способны решать такие проблемы, которые
не под силу ни одному из агентов в отдельности. МАС состоит из множества
агентов, которые помещены в общую среду, от которой они получают данные,
отражающие события, происходящие в среде, интерпретируют их и воздействуют на среду.
В последнее время все большее значение при создании МАС приобретает
эволюционный подход, Swarm Intelligence, позволяющий создавать компьютерные системы нового поколения, использующие принципы самоорганизации
и эволюции, характерные для поведения живых систем, например, колонии муравьев или роя пчел.
Решение любой сложной задачи в такой системе может формироваться
эволюционным путем, по мере возникновения внешних и внутренних событий,
за счет взаимодействия десятков и сотен тысяч агентов, непрерывно конкурирующих и кооперирующихся друг с другом. В таком подходе очень трудно или
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
даже невозможно просчитать заранее все последствия принятия агентом того
или иного решения на текущем шаге, например, в силу комбинаторно растущей
сложности вычислений. Поэтому обычно принимается решение (делается
«проба»), которое позволяет улучшить ситуацию, а далее это решение пересматривается при первой же возможности, поскольку этот процесс меняет условия для других агентов, что приводит к новым ситуациям. Фактически, при
таком подходе решение задачи находится методом «проб и ошибок», что оказывается очень близко подходу людей к решению сложных задач. Такой подход
позволяет решать на практике задачи самой высокой сложности, не поддающиеся решению другими способами, например, в области планирования и оптимизации ресурсов в реальном времени.
Для реализации мультиагентных систем вводятся специальные классы
агентов задач, операций и ресурсов, действующих от лица и по поручению своих владельцев, которые способны выявлять конфликты и достигать компромиссы в порождаемых ими динамических сетях операций, формирующихся на основе соответствующих протоколов взаимодействия и проведения переговоров.
Разработаны принципы построения и функционирования агентов, а также протоколы их взаимодействий для коллективного управления подвижными объектами, спроектированы средства для поддержки жизненного цикла агентов как в
части реакции на события и построения планов, так и их исполнения и корректировки в реальном времени, спроектированы средства для поддержки жизненного цикла агентов (Рисунок 9 – Рисунок 10).
Жизненный цикл агента состоит из следующих фаз [46]:
­ восприятие окружающего мира – percept;
­ определение цели (задачи) – goal;
­ построение плана – plan;
­ принятие плана к исполнению – commit;
­ исполнение плана – execute;
­ сравнение полученных результатов и ожидавшихся – plan vs. fact;
­ изменение поведения» – learn.
Этот цикл называется PCX-циклом (по наименованию фаз: plan – commit
– execute). PCX-цикл каждого агента независим, т.е. фазы работы агента не зависят от того, в какой фазе своего жизненного цикла находятся другие агенты.
Таким образом, часть агентов в системе могут заниматься, например, планированием, а другие исполнением своих планов.
Каждый раз, когда агент получает управление от системы, личность агента – Agent Personality – решает, как себя вести в данной ситуации: продолжить
исполнение ранее начатой задачи, инициировать обработку новой задачи на основании изменений во внешнем мире или внутреннем состоянии, вернуться к
ранее отложенной задаче и пр. Т.е. агент оценивает имеющуюся у него информацию с точки зрения своей цели и выбирает наиболее адекватный с его точки
зрения вариант действий.
Конструкция агента представлена на Рисунок 9.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
От Диспетчера агентов
Очередь событий
Базовая часть
Жизненный цикл
агента
Библиотека ролей
агента
Отложенная роль с
сохраненным контекстом данных
Личность агента
(Принятие решений)
Выполнить шаг роли
и перейти к следующему состоянию
Роль агента
Инициализировать процесс
Ожидать событие от другого
агента и перейти к следующему
Сенсоры
Диаграмма
состояний
Ожидать событие, которое придет первым, и
перейти к следующему
Исполнители
Уничтожить процесс
Предметная область
Рисунок 9 – Конструкция агента
Новая информация может поступать в индивидуальную сцену агента, т.е.,
индивидуальное представление о внешнем мире и о себе. Сенсоры создают
объекты – события, которые помещаются в очереди. Очереди обрабатываются в
Agent Personality, которая работает согласно PCX-циклу. События создаются в
фазе восприятия (perception).
В фазе планирования (planning) определяется реакция агента на эти события, т.е. на внешнее событие или внутреннее состояние. Эту реакцию определяет текущее состояние агента. При этом агент использует знания о мире, содержащиеся в онтологии, и свой собственный опыт. В процессе планирования
агент создает планы действий, оценивает потенциальные результаты с точки
зрения критериев достижения цели. Из имеющихся вариантов агент выбирает
лучший вариант на основании значения свертки критериев. Свертка критериев
– это общая оценка варианта решения по критериям.
Выбранный план принимается к исполнению на фазе commit.
Далее агент переходит в фазу исполнения (execution) согласно выбранному плану действий. В фазе исполнения агент использует имеющиеся у него исполнительные механизмы - эффекторы, обеспечивающие посылку сообщений,
модификацию общей сцены, выполнение расчетов и т.д.
Блок памяти (Agent Memory) поддерживает структуру данных агентов для
хранения значений атрибутов концептов в сцене, а также строит таблицу решений, в которой агент размещает варианты решений, и по которой он может
осуществлять сортировку вариантов.
Блок коммуникаций обеспечивает поддержку асинхронного обмена со-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
общениями между агентами и с пользователем без останова системы.
После того, как агент создается, он регистрируется в системе. Формируется Agent Personality. Новый агент получает из онтологии необходимую для
его функционирования начальную информацию:
­ задачи, соответствующие его классу;
­ цели, критерии, ограничения, которые формируют логику принятия решений
для задач, выполняемых агентом.
Далее запускается личность агента – Agent Personality, реализующая жизненный цикл агента. По окончании жизненного цикла регистрация агента в
системе удаляется. Об этом уведомляются агенты, связанные с данным, после
чего агент удаляется из системы.
На Рисунок 10 показаны фазы жизненного цикла агента.
Знания агента
Вход (сообщения,события)
Жизненный цикл агента
Восприятие
Планирование
Сенсоры
Исполняющая
система
Личность агента
Подтверждение
Исполнение
Выход
(сообщения, события)
Память агента
Индивидуальная
онтологическая
сцена (модель
мира)
Текущие планы
Рисунок 10 – Фазы жизненного цикла агента
Требования к системам управления мобильными ресурсами, сформулированные ранее, приводят к необходимости обеспечения такой архитектуры многоуровневых агентов, которая обладает следующими свойствами:
­ Собственное, независимое представление о мире. Позволяет агенту существовать и размышлять независимо от других агентов, взаимодействуя с ними
с помощью сообщений. При этом неважно физическое нахождение агентов –
на одной или разных рабочих станциях.
­ Ориентированность на достижение целей. Позволяет задавать деятельность
и размышления агента с помощью различных моделей, например убеждения
– желания – цели – намерения.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
­ Формализованная модель размышлений, направленных на достижение целей. Формализованная модель позволяет не только описывать модели поведения агентов, но и менять их без перепрограммирования системы.
­ Обучение и накопление опыта. Накопление опыта заключается в постоянном
анализе эффективности текущей модели размышлений и изменении модели.
Такая возможность позволяет агенту адаптироваться к изменению во внешней среде.
­ Работа в операционном режиме. Агент должен обеспечивать быструю реакцию на входные события и планирование действий в зависимости от оставшегося времени.
­ Построение и применение сложных, многоходовых планов. Для достижения
намеченной цели агенты должны не просто выполнять атомарные или составные действия, а составлять планы выполнения этих действий и корректировать их во время исполнения в зависимости от состояния. Данная возможность позволяет агенту строить несколько независимых планов по изменению своего состояния и согласованного изменения состояния других агентов. Такие планы могут быть конфликтующими или совместимыми. Агент в
своих рассуждениях и реакции на внешние события должен легко оперировать различными планами.
Система, построенная на агентах, удовлетворяющих этим требованиям,
способна осуществлять планирование и принятие решений в распределѐнных
средах, поддерживает гибкую настройку за счет формализации и возможности
изменения целей и моделей поведения агентов, способна к адаптации к изменяющимся условиям, а также поддерживает работу в режиме, близком к режиму реального времени [43-46]. Отметим, что программная реализация должна
поддерживать значительное количество агентов (тысячи) в рамках одной рабочей станции, для сокращения накладных расходов при межсерверной коммуникации агентов и возможности образования «регионов» – скопления агентов, которые ведут интенсивные переговоры.
В настоящее время существует ряд программных систем, стандарты и
промежуточное программное обеспечение (middleware), которые описывают и
реализуют принципы реактивных агентов, делиберативных и многослойных
архитектур. Рассмотрим представителей каждой из архитектур.
В качестве примера реактивных агентов можно выделить наиболее известное промежуточное программное обеспечение JADE [40]. Эта система позволяет строить агентов на уровне активностей (называемых также ролями или
поведением). Предлагаются сервисы по обмену сообщениями, нахождению
других агентов и сервисов (discovery) и публикации агентами предлагаемых услуг.
Одним из примеров реализации делиберативной архитектуры является
система Jadex [41]. Целью исследовательского проекта Jadex является создание
рационального слоя на базе инфраструктуры JADE, обеспечивающего возможность построения агентов. Jadex реализует модель BDI, расширяя агентов Jade
«убеждениями», «целями» и «намерениями», которые могут быть созданы
внутри агента. Для достижения своих целей агент выполняет планы, являю-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
щиеся процедурными средствами, кодированными в Java. В Jadex предусмотрена библиотека планов, которыми может оперировать система. Для пополнения такой библиотеки программист декомпозирует функциональность, которую
должен выполнять агент, в отдельные планы.
Наибольший интерес представляет реализация многоуровневых архитектур, т.к. именно они могут являться основой для построения мультиагентных
систем оперативного принятия решений. В качестве примера смешанной архитектуры рассмотрим архитектуру InteRRaP.
INTEgration of Reactive behavior and RAtional Plannig – объединение реактивного поведения и рационального планирования. InteRRaP проектировался с
учетом уменьшения разрыва между реактивностью и рассудительностью.
Структура агента имеет послойную организацию, что характерно для смешанных архитектур.
Главная идея архитектуры InteRRaP состоит в разделении агента на три
уровня (в соответствии с идеей смешанной архитектуры, т.е. реактивность и
способность к рассуждениям):
­ уровень поведения (behavior-based layer) – включает реактивность и методы
решения стандартных (простых) задач;
­ уровень локального планирования (local planning layer) – предоставляет механизм для реализации целеустремленности;
­ уровень совместного планирования (cooperative planning layer) – служит для
взаимодействия с другими агентами.
Агент получает на вход ощущение и выдает на выходе определенное действие. Для агента вводится понятие состояния (mental state) и базовых функций,
которые могут изменять это состояние.
У InteRRaP агента можно выделить следующие составные части, что в
целом соответствует BDI модели:
­ ощущение (perception) агента;
­ множество убеждений (beliefs) – информационное состояние;
­ ситуация (situation) – состояние среды. Она определяется как некоторая
структура (множество), состоящая из убеждений агента;
­ множество целей (goals), цель можно определить как состояние среды (ситуацию);
­ множество намерений (intentions), намерение – сформировавшийся план
действий, который впоследствии выполняется.
К недостаткам архитектуры InteRRaP можно отнести требовательную к
аппаратным ресурсам реализацию (что затрудняет использование значительного количества агентов в системе с небольшими ресурсами), а также лимитированное количество слоев в архитектуре агента, которая не предусматривает
расширение. Архитектура не предусматривает специальных средств для обеспечения работы многих агентов на одной рабочей станции в режиме, близком к
режиму реального времени.
Для реализации концепции ПВ-сетей был разработан специализированный набор компонент платформы для создания мультиагентных систем.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
2.3 Мультиагентная платформа планирования
Архитектура мультиагентной платформы планирования включает в себя
онтологию для хранения знаний о предметной области и логике принятия решений по планированию и модуль планирования, обеспечивающий необходимые вычислительные возможности для работы мультиагентного мира [1-2, 7085].
2.3.1 Онтология – модель знаний предметной области
Для описания знаний, необходимых агентам, входящим в состав МАС,
используется онтологический подход, согласно которому знания должны быть
отделены от программного кода системы и должны храниться в онтологии,
представляющей собой сеть понятий и отношений предметной области.
Онтология – это формализованные концептуальные знания о предметной
области, представленные в форме, допускающей компьютерную обработку и
используемые при принятии решений. Концептуальность знаний онтологии означает, что эти знаний формулируются в терминах основных концептов (наиболее общих понятий и отношений), описывающих фрагменты окружающего
мира.
Онтология – это попытка всеобъемлющей и детальной формализации некоторой области знаний с помощью концептуальной схемы. Обычно такая схема состоит из структуры данных, содержащей все релевантные классы объектов, их связи и правила (теоремы, ограничения), принятые в этой области. Этот
термин в информатике является производным от древнего философского понятия «онтология». Термин «онтология» используется как для обозначения базы
знаний в целом, содержащей описания данных с помощью некоторой концептуальной схемы, так и для обозначения собственно концептуальной схемы, при
этом оперативная информация, отражающая текущее состояние объектов, специфицированных с помощью концептов и отношений, выделяется в так называемую «сцену».
На Рисунок 11 – Рисунок 13 показаны основные объекты онтологии
транспортной логистики.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Объект
Ресурс
Заказ
Груз
Географическая точка
точка
Маршрут
Транспортная инструкция
инструкция
Точка исполнения
исполнения
Рисунок 11 – Основные объекты онтологии транспортной логистики
Расписание:
Параметры ресурса:
 Оптимальная скорость
 Вместимость
 Начальное положение
 Время доступности
 База приписки
 Необходимость возврата на базу
Рисунок 12 – Понятие ресурса
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Заказ:
Заказ
Транспортная
инструкция:
Транспортная
инструкция
Точка
исполнения:
Точка
исполнения
Груз:
Груз
Транспортные инструкции
Точки исполнения




Географическая точка
Тип операции
Длительность операции
Возможное время начала
операции
 Возможное время окончания операции
 Тип руза
 Объем груза
 Вес груза
Рисунок 13 – Понятие и детализация заказа
Разработана структура онтологии для описания основных концептов и
отношений предметной области. Классы концептов онтологии организованы в
иерархию на принципах наследования, концепт характеризуется свойствами
(атрибутами). В онтологии транспортной логистики в качестве основных можно выделить следующие ключевые понятия (концепты) и их атрибуты:
­ Carrier Company – компания-перевозчик, владеющая грузовиками. В системе может быть определено несколько перевозчиков с разными стратегиями.
Атрибуты:
 Name – название компании-перевозчика (тип string);
­ Customer – клиент перевозчика, для разных клиентов могут быть определены различные стратегии перевозки. Атрибуты:
 Name – название клиента (тип string);
­ Transportation instruction (TI) – заказ на перевозку от заданного клиента,
описывающий перевозимый груз (или набор грузов), откуда и куда перевозится груз, особые условия перевозки и т.д. Атрибуты:
 Name – название (тип string),
 Creation Time – дата создания (тип date),
 Priority – приоритет выполнения (тип double),
 Status – текущее состояние TI (тип int):
modified – TI может быть модифицирована,
cancelled – TI может быть удалена,
planned –TI успешно запланирована в последнем сеансе планирования,
unplanned – TI не запланирована в последнем сеансе планирования;
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
­ Cargo – груз, который могут перевозить перевозчики (обычно в паллетах),
груз может требовать или желать специальных условий перевозки. Атрибуты:
 Volume – вес груза, который может быть транспортирован в соответствии
с TI (тип double),
 Waypoint – операции транспортной логистики, выполняемые над грузами
(погрузка - collect cargo, выгрузка - drop cargo и т.д.). Атрибуты:
 Duration – продолжительность выполнения операции (тип int),
 LocationName – название географической точки, в которой должна быть
выполнена операция по обработке груза (тип string),
 TimeWindowFrom – начало периода времени, в течение которого должна
быть выполнена операция (тип date),
 TimeWindowTill – окончание периода времени, в течение которого должна
быть выполнена операция (тип date),
 Type – тип операции по обработке груза (тип int):
collect – операция погрузки,
drop – операция выгрузки,
none – операция отсутствует;
­ Resource – перевозчик компании (грузовик), характеризуемый вместимостью, раскраской, обеспечиваемыми условиями перевозки (холодильник),
возможностью использования прицепов и т.д. Атрибуты:
 BaseLocation – географическая точка размещения депо (тип string);
 Capacity – максимальная грузоподъемность (тип int);
 InitialDateTime – дата появления ресурса в системе (тип date);
 InitialLocation – начальная точка размещения ресурса в системе перед началом планирования (тип string);
 LoadingSequence – определяет последовательность разгрузки ресурса (тип
int):
stack – последовательность в соответствии с дисциплиной “последним
пришел - первым вышел”,
random – случайная последовательность;
­ GeoLocation – географическое место выгрузки или погрузки товара на карте
транспортной сети компании. Атрибуты:
 Name – название (тип string),
 FixedTime – постоянное время, требуемое для обслуживания ресурса в
географической точке (не зависит от количества операций; тип int),
 TimePerUnit – время, требуемое для обработки одной единицы груза (не
зависит от типа операции; тип int);
­ Pattern – типовой маршрут перевозки. Атрибуты:
 Name – название (тип string),
 Price – стоимость TI, соответствующей паттерну (тип double).
Наряду с базовыми концептами в онтологии транспортной логистики используются следующие базовые отношения:
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
Клиент имеет заказ;
Заказ содержит груз;
Заказ содержит транспортную инструкцию;
Флот включает грузовики;
Флот включает прицепы;
Грузовик имеет расписание;
Консолидация транспортных инструкций объединяет отдельные инструкции;
Поездка имеет транспортную инструкцию;
Инструкция имеет расписание;
Инструкция состоит из операций;
Клиент связан с транспортными инструкциями – HaveTI;
Операции связаны с перевозчиками и грузами – HaveCargo;
Ресурсы (перевозчики) связаны с их владельцами – HaveOwnerCompany;
Ресурсы приемлемы для выполнения транспортной инструкции –
AllowedResource;
Транспортные инструкции связаны с отдельными операциями над грузами
(инструкция включает эти операции) – HaveWayPoint;
Перевозчик связан с типовыми маршрутами – CarrierHasPattern;
Маршрут связан с географическими точками – PatternIncludesGeoLocation.
Диграмма классов онтологии транспортной логистики показана на Рисунок 14.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Customer
(from ObjectClass)
Name : String
1..1
0..n
0..1
HaveTI
(from Relation)
CarrierCompany
(from ObjectClass)
TransportationInstruction
1..1
(from TransportationObject)
1..1
1..1
1..1
1..n
1..n
HaveWaypoint
TransportationObject
Company
(from Relation)
1..1
(from ObjectClass)
(from TransportationObject)
0..n
HaveOwnerCompany
(from Relation)
0..1
1..1
AllowedResource
Waypoint
(from ObjectClass)
1..1
(from Relation)
0..n
0..n
1..1
1..1
GeoLocation
(from TransportationObject)
Resource
FixedTime : Integer
Name : String
(from TransportationObject)
1..1
0..n
0..1
1..1
0..n
HaveCargo
1..n
(from Relation)
0..n
CarrierHasTIPattern
1..n
Quantity : Double
(from Relati...
1..1
Cargo
(from ObjectClass)
PatternIncludesGeoLocation
(from Relati...
0..n
Volume : Double
1..1
Pattern
(from ObjectClass)
1..1
Рисунок 14 – Диаграмма классов онтологии транспортной логистики
Модель знаний предметной области (онтология) может быть представлена в виде дерева наследования (в правой части экрана) или в виде семантической сети, вершинами которой являются концепты, а ребрами – отношения между концептами (Рисунок 15).
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Описание классов понятий
и отношений
Рисунок 15 – Способы представления онтологии
2.3.2 Агенты мира транспортной логистики
Заказы и ресурсы имеют агентов, представляющих их интересы в системе. Кроме них рекомендуется использовать:
­ агента менеджера, отвечающего за распределение ресурсов, который позволяет в значительной степени повысить эффективность планирования за счѐт
сокращения времени на принятие решений,
­ агентов диспетчера, оператора и водителя, позволяющих контролировать все
происходящие в системе события и выполнять операции, которые должны
осуществляться пользователями системы в соответствии с их рабочими процессами,
­ агента руководителя, информирующего всех лиц, принимающих решения
(ЛПР), о текущем положении дел и событиях, напрямую или косвенно
влияющих на эффективность ведения бизнеса.
В Таблица 2 представлен список агентов транспортной сети.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Таблица 2 – Список агентов транспортной сети
Агент
Назначение
Агент заказа
Ищет лучшие варианты размещения на грузовиках (например, по цене)
Агент грузовика
Ищет заказы для увеличения эффективности
своего использования
Агент стороннего перевозчика Ищет стороннего перевозчика с лучшим соотношением цены и качества
Агент маршрута
Ищет лучший маршрут для поездки (минимальной длины)
Агент водителя
Ищет поездки, удовлетворяющие предпочтениям водителя (длинные поездки, работа
только в рабочее время и т.д.)
Агент техосмотра
Ищет возможности сделать профилактический осмотр грузовика
Агент топлива
Ищет лучшие возможности для заправки машины по маршруту следования
Финансовый агент
Выбирает варианты оплаты внешним перевозчикам (например, минимум предоплаты)
Агент груза
Проверяет условия транспортировки (наличие
машины с холодильником)
Агент диспетчера
Выбирает политику активации агентов
Агент менеджера
Принимает решения по распределению ресурсов
Агент компании
Следит за интересами компании и переключает стратегии другим агентам
Агенты имеют следующие функциональные возможности:
­ Company Agent
 мониторинг ситуации по основным критериям,
 реагирует на изменение критериев пользователем,
 выбирает проблему для решения (слишком высокий риск, низкая прибыль и т.д.),
 изменяет стратегии работы агентов;
­ Order Agent
 следит за изменениями в маршруте,
 может войти, модифицировать или покинуть маршрут,
 создает новый маршрут (если нет подходящего),
 рассчитывает прибыль,
 ищет лучшие маршруты и ведет переговоры по подвижкам по заданным
критериям,
 реагирует на предложения от других маршрутов;
­ Trip Agent
 реагирует на предложения изменить маршрут для заказов,
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
 находит разные маршруты из А в В (минимальной дистанции, высокой
скорости, максимальной комфортности и т.д.),
 ищет подхваты для построения круговых маршрутов,
 ищет подходящий грузовик,
­ Truck Agent
 следит за изменениями в маршрутах,
 делает предложения маршрутам, когда складывается нужного размера
маршрут,
 рассчитывает стоимость перевозки,
 ищет варианты лучшего использования;
­ Driver Agent
 обслуживает предпочтения водителя,
 ищет подходящие грузовики и маршруты;
­ Fuel Agent
 определяет лучшие места заправки на маршруте,
 реагирует на изменения в ценах на заправках,
 инициирует пересмотр маршрутов при изменении цены на топливо.
Архитектура мира агентов транспортной сети представлена на Рисунок
16.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 16 – Архитектура мира агентов транспортной сети
2.3.3 Алгоритм переговоров агентов
Основной задачей мультиагентной системы в рассматриваемой области
является построение и поддержание баланса интересов заказчиков, самой компании, водителей и других участников процесса принятия решений. При этом
каждый участник взаимодействия может иметь свои потребности и возможности, реализуемые через роли заказов и ресурсов участников, постоянно стремящихся найти друг друга и установить связи между собой, бронируя ресурсы
под заказы.
Алгоритм переговоров агентов в системе достаточно прост. Основная
сложность с принятием решений связана с критериями микроэкономики, которые используются для анализа различных опций. В общем и целом данные алгоритмы можно описать следующим образом.
Каждый из ресурсов получает собственного агента, имеющего цель и
знания о конфликтах. Если для выполнения одного заказа используются сразу
несколько типов ресурсов, в системе должна быть предусмотрена возможность
матчинга данных ресурсов. В таких случаях группа ресурсов должна также
иметь собственного программного агента. К примеру, когда есть возможность
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
выбора одного из нескольких водителей и одной из нескольких машин для выполнения определѐнного заказа (такие ситуации возникают очень часто), система должна самостоятельно проанализировать возможность водителя управлять тем или иным автомобилем (совместимость), создать персональных агентов для водителя и автомобиля, сопоставить данные водителя и транспортного
средства на основе определѐнных критериев, после чего создать агента пары
водитель-автомобиль.
Каждый заказ, поступающий в систему, получает в пользование собственного программного агента, который владеет всей информацией о заказе.
Данный агент должен уметь извлекать подробные данные о заказе из онтологии
системы, включая предпочитаемый тип автомобиля, особые требования к водителю или автомобилю, тип оплаты, условия соглашений и др.
Для обеспечения работы в реальном масштабе времени планирование
должно происходить достаточно быстро. Для этого система заблаговременно до
начала планирования подготавливает мультиагентный мир, исключая варианты
размещения, которые однозначно невыгодны, и ранжирует оставшиеся варианты по принципу наибольшей выгоды (прибыльности). При выполнении подобных операций могут использоваться эвристики, основанные на анализе географических данных (например, автомобили, расположенные слишком далеко от
места погрузки, будут игнорироваться), статистики (некоторые типы автомобилей, как правило, используются для выполнения строго определѐнных типов
заказов) или требований к автомобилю (многие виды товаров можно перевозить только с использованием строго определѐнного вида транспорта, например, скоропортящиеся продукты транспортируются в прицепах рефрижераторного типа, такси могут быть как для курящих, так и для некурящих пассажиров
и т.д.). Подобные требования содержатся в стандартах на грузоперевозки или
предоставляются непосредственно заказчиком.
Переговоры между агентами ведутся по следующему алгоритму: заказ
делает предложение всем отобранным ресурсам и определяет виртуальную
стоимость собственной транспортировки. Ресурсы анализируют возможную
выгоду от выполнения заказа и либо соглашаются, либо отказываются от его
выполнения. Тогда, когда для принятия такого решения необходимо участие
водителя или другого ЛПР, оно ограничивается по времени. Если ресурс соглашается, но только при условии некоторых изменений в требованиях или в
цене (например, хочет получить больше денег), его предложение формируется
в заранее заданном формате.
После получения всех возможных предложений агент заказа принимает
окончательное решение и выбирает одного агента ресурса, который затем вносит изменение в собственное расписание. В случае если в результате переговоров так и не удалось найти окончательное решение или же решение было принято только после значительных изменений в первоначальных требованиях,
ЛПР (диспетчер, оператор или менеджер) получает соответствующее уведомление и может выполнить планирование самостоятельно в ручном режиме или
инициировать циклическое планирование.
Алгоритм планирования представлен на Рисунок 17.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 17 – Алгоритм автоматизированного планирования в системе
планирования грузоперевозок
Пример протокола взаимодействия между агентами в процессе планирования приведен на Рисунок 18.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Протокол задачи планирования
Агент заказа
Ввести заказ
Агент грузовика
Актуализация заказа
Запрос к грузовикам на определение расстояния до цели
Расстояние до цели
Определить расстояние
до цели
Сформировать список
ближайших грузовиков
Запрос о характеристиках грузовиков
Определить характеристики
грузовиков
Прот.2
Характеристики грузовиков
Выбор ближайшего к цели
грузовика с соответствующими
характеристиками
Подтвердить
выбор
Вернуться в
Очередь событий
Рисунок 18 – Пример протокола взаимодействия между агентами при решении задачи планирования
Взаимодействие агентов в процессе пегеговоров при планировании представлено на Рисунок 19.
Пример хода переговоров по подвижкам заказов в процессе планирования
приведен на Рисунок 20 – Рисунок 22.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 19 – Взаимодействие между агентами в процессе переговоров
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Шаг 1
Заказ 4
Заказ 2
Заказ 1
Заказ 3
D1
Шаг 2
Заказ 4
Заказ 1
Заказ 2
Заказ 3
D2
Рисунок 20 – Шаги 1 и 2. Проведение переговоров при поступлении нового заказа: Заказ 4 меняет свое положение и смещается вправо
Шаг 2
Заказ 4
Заказ 2
Заказ 1
Заказ 3
D2
Шаг 3
Заказ 4
Заказ 1
Заказ 2
Заказ 3
D3
Рисунок 21 – Шаги 2 и 3. Дальнейшие переговоры: в результате переговоров
внутри системы Заказ 2 смещается вправо
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Шаг 4
Заказ 4
Заказ 1
Заказ 2
Заказ 3
Заказ 2
Заказ 3
D3
Шаг 5
Заказ 4
Заказ 1
Рисунок 22 – Шаги 4 и 5. Достижение итогового решения: в результате переговоров Заказ 1 смещается влево и Заказ 4 размещается без конфликтов с другими
заказами
2.3.4 Реализация мультиагентной платформы планирования ресурсов
Основной функциональной возможностью данной платформы является
работа в режиме реального времени и адаптивная реакция в ответ на поступающие извне события. Для этого информация о данных событиях должна появляться сразу же после их поступления. В связи с этим система должна иметь
возможность определять географические координаты всех мобильных ресурсов
(например, с помощью GPS), сопоставлять их с электронной картой территории
для визуализации всей транспортной сети компании, определять расстояния
между различными пунктами на карте и обеспечивать постоянную обратную
связь с водителями для обмена информацией. Чтобы реализовать данную
функциональность, наиболее оптимальным решением является использование
уже имеющихся на рынке геоинформационных и картографических сервисов.
Таким образом, в платформе должны быть богатые возможности по интеграции
с новыми сервисами.
На Рисунок 23 представлена логическая архитектура системы. Для создания мультиагентных систем планирования по принципу полной загрузки
предлагается использовать трѐхуровневую архитектуру, включающую серверы
бизнес-логики и базы данных, а также способную получать оперативную информацию от внешних веб-сервисов и взаимодействовать с коммуникационными устройствами пользователей. При этом база знаний отделена, с одной сто-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
роны, от операционной платформы, обеспечивающей основные условия для
функционирования инфраструктуры системы, включая безопасность и обработку отказов, а с другой – от слоя бизнес-логики, обеспечивающего возможности дальнейшего развития системы.
Рисунок 23 – Логическая архитектура системы
На Рисунок 24 представлена физическая архитектура системы. Для различных систем, разрабатываемых на базе мультиагентной платформы, варианты использования готовых компонентов могут несколько отличаться друг от
друга. Причиной тому является разница в требованиях к внедрению в различных компаниях, разный уровень «технологической зрелости» (технического оснащения), а также специфика уже используемого в компаниях программного
обеспечения.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 24 – Физическая архитектура системы
При реализации систем планирования может использоваться такая современная модель реализации программного обеспечения, как SaaS (Software as a
Service, ПО как сервис), при которой заказчики платят не за владение программным обеспечением как таковым, а за его использование, что позволяет
распределять стоимость системы по времени использования и количеству пользователей. Данная модель может стать очень востребованной среди небольших
транспортных компаний, не имеющих возможности единовременной оплаты
разработки информационных систем, но готовых платить небольшую ежемесячную плату в расчѐте на каждое используемое транспортное средство.
2.4 Примеры адаптивного планирования заказов в реальном времени
В сфере управления грузоперевозками предлагаемое решение позволяет
планировать водителей, грузовики и прицепы как собственного, так и привлекаемого транспортного флота для выполнения поступающих в реальном времени заказов на транспортировку. Заказы, как правило, поступают от постоянных
клиентов компании (с которыми имеются специальные договорѐнности). Однако в то же самое время имеется категория случайных заказов, формируемых отдельно, выполнение которых не является обязательным. Транспортная сеть
компании характеризуется большой удалѐнностью мест доставки грузов; горизонт планирования включает от 1 до 7 дней.
В большинстве компаний используемое традиционное программное
обеспечение позволяет лишь частично решить проблему с планированием гру-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
зоперевозок: как правило, планирование осуществляется в ручном режиме, что
неудобно и малоэффективно. Помимо прочего, существует высокая потребность в создании сетей для совместной работы диспетчеров и менеджеров, планирующих зависимые друг от друга заказы или одни и те же транспортные ресурсы (например, при обратной загрузке) [1-2].
Кроме того, в системе должна обеспечиваться возможность инкрементального планирования в масштабе реального времени в ответ на поступающие
события, когда заказ загружается в систему, обрабатывается, автоматически
планируется, и результаты планирования предоставляются водителю. Планирование может вызываться переговорами диспетчеров и водителей (или компаний, предоставляющих водителей) о цене и сроках. Для удовлетворения всех
вышеназванных требований необходимо использовать мультиагентные системы.
На Рисунок 25 – Рисунок 27 представлены образцы, иллюстрирующие
интеллектуальную логику принятия решений, причем основной задачей является адаптивное перепланирование новых заказов в реальном времени.
Первый пример (Рисунок 25) иллюстрирует выбор системой наиболее выгодного варианта размещения с учѐтом возможных рисков.
На Рисунок 26 представлена ситуация, когда собственный грузовик компании запланирован для выполнения заказа 1 и уже находится в пути на погрузку. Сразу же после поступления нового заказа 2 система принимает решение использовать для этого заказа уже запланированный собственный грузовик
вместо свободного, но дорогостоящего стороннего перевозчика и осуществляет
перепланирование заказа 1, подбирая для его выполнения более подходящий
ресурс.
На Рисунок 27 проиллюстрирован вариант оптимизации использования
флота путѐм поиска компромиссов. Первоначально, два грузовика имели независимые друг от друга расписания, однако, в результате планирования нового
заказа, система предложила менеджеру согласовать с клиентом заказа 2 возможность небольшой задержки с загрузкой. Если такой вариант приемлем, то
возможные потери с лихвой компенсируются за счѐт более оптимального распределения ресурсов (грузовиков).
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 25 – Планирование грузоперевозок: Ситуация 1
Рисунок 26 – Планирование грузоперевозок: Ситуация 2
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 27 – Планирование грузоперевозок: Ситуация 3
Таким образом, мультиагентное адаптивное планирование позволяет добиться следующих преимуществ:
­ обеспечение индивидуального подхода к выполнению каждого заказа;
­ автоматизация основных операций операторов по планированию ресурсов;
­ накопление знаний о специфике бизнеса, позволяющих уточнять и совершенствовать правила принятия решений при планировании;
­ повышение оперативности принятия решений и сокращение времени планирования;
­ осуществление эффективного наглядного оперативного управления имеющимися заказами, повышение операционной эффективности;
­ своевременное извещение операторов о возможных проблемах (отсутствие
заказов на будущее, расхождение между «планом» и «фактом», неэффективное использование транспортных средств и т.д.);
­ получение соответствующей комплексной систематизированной отчетности,
снижение издержек по составлению и систематизации отчетной документации.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3 МУЛЬТИАГЕНТНАЯ СИСТЕМА УПРАВЛЕНИЯ
ТРАНСПОРТНЫМИ РЕСУРСАМИ (МАС УТР)
Рассмотрим мультиагентную систему управления транспортными ресурсами, реализованную на основе мультиаегнтного подхода и метода адаптивного
планирования.
3.1 Назначение системы
Мультиагентная система управления транспортными реурсами (МАС
УТР) предназначена для использования:
­ менеджерами центрального офиса и филиалов ТЛК (для приѐма и автоматизированного планирования заявок);
­ руководителями центра и филиалов ТЛК (для мониторинга работы).
МАС УТР предназначена для выполнения следующих функций:
1. Сбор и регистрация заявок на перевозку грузов, вводимых вручную с помощью регистрационной формы МАС УТР;
2. Мониторинг текущего статуса транспортных средств и заявок (в каком состоянии на данный момент находится заявка, каково отклонение от плана
при его наличии и т.д.) путем организации обратной связи с водителем;
3. Адаптивное автоматическое планирование: назначение ресурсов (транспортных средств, водителей) для выполнения поступающих в режиме реального времени заявок на транспортировку грузов с помощью подсистемы автоматического планирования;
4. Планирование поездок с учѐтом индивидуальных особенностей заказов, текущего распределения транспортных средств по заказам и их предполагаемого географического положения на момент начала выполнения заявок;
5. Ведение основных справочников: контрагентов, ресурсов, городов и т.п.;
6. Введение справочников атрибутов (тип груза, объем, грузоподъемность и
пр.);
7. Визуализация текущего расписания в разрезе любого из имеющихся типов
ресурсов за выбранный временной интервал;
8. Формирование печатных форм: при необходимости пользователь может создать с помощью редактора печати заявки шаблон требуемого документа и
использовать его в дальнейшем;
9. Формирование отчетов для руководителя на основании критериев эффективности (график, показывающий доход, себестоимость и рентабельность по
запланированным заявкам; график загрузки водителей и тягачей; график,
отображающий уровень сервиса и т.д.);
10.Учет особенностей использования ресурсов с помощью редактора правил.
В Таблица 3 приведены используемые термины.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Диспетчер
Заказчик
Заявка
Клиент
Мастер - план
Перевозчик
Ресурсы
Собственные
ресурсы/флот
Сторонние
ресурсы/флот
Товарнотранспортная
накладная (ТТН)
Экспедитор
Таблица 3 – Термины МАС УТР
Работник оперативного отдела, координирующий
и контролирующий распределение заявок и осуществляющий взаимодействие с Собственными
ресурсами
Юридическое/физическое лицо, размещающее
Заявку на перевозку груза и производящее оплату
Событие, связанное с поступлением от Заказчика
запроса на оплачиваемую перевозку груза
Транспортно-логистическая компания (ТЛК)
План который отражает предполагаемую прибыль, выручку, километраж, затраты на перевозку. Как правило, он составляется в конце текущего месяца на следующий. на основании заключенных с клиентом долгосрочных договоров
Юридическое лицо, осуществляющее перевозку
Водитель/Тягач/Прицеп
Ресурсы, находящиеся в оперативном управлении ТЛК
Ресурсы, принадлежащие Перевозчику, не находятся в оперативном управлении ТЛК
Документ учета движения товарно-материальных
ценностей; составляется грузоотправителем для
каждого грузополучателя отдельно на каждую
поставку
Юридическое лицо, которое осуществляет поиск
перевозчика, выступает в качестве посредника
3.2 Установка и запуск системы
Для корректной работы с системой рабочая станция пользователя должна
удовлетворять следующим основным требованиям к аппаратной и программной части:
­ Процессор Intel Pentium 4 с тактовой частотой не менее 1,6 Ггц;
­ Объем оперативной памяти – не менее 512 Мб (рекомендуется – 1024 Мб);
­ Операционная система Microsoft Windows XP Service Pack 2 / Microsoft Windows Vista;
­ Microsoft .NET Framework 3.5;
­ Пакет офисных программ Microsoft Office 2000 или выше.
Для работы с системой необходимо запустить следующие компоненты:
­ Приложение для доступа к БД системы;
­ Подсистему автоматического планирования;
­ Собственно клиентское приложение.
При запуске клиентского приложения необходимо в окне аутентифика-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ции пользователя ввести логин и пароль (Рисунок 28).
Рисунок 28 – Окно аутентификации пользователя
Описываемая система имеет физическую архитектуру клиент-сервер на
основе технологий Java Enterprise Edition версии 5.0. Для доступа к данным используется технология Enterprise Java Beans 3.0 Persistence и Hibernate, что позволит достаточно просто сменить СУБД в случае необходимости. Рекомендуемые СУБД – MS SQL Server 2000/2005 или Oracle 10g.
3.3 Начало работы с системой
3.3.1 Интерфейс и главное окно системы
МАС УТР обладает графическим интерфейсом пользователя и имеет
большинство стандартных элементов интерфейса, таких как меню, кнопки команд, вкладки, списки, кнопки-флажки и др.
Все открытые окна и документы системы отображаются в виде отдельных
вкладок, которые располагаются под меню системы. Несохраненные документы помечаются значком * (звездочка) рядом с наименованием.
Пользователь может располагать закладки открытых документов в любой
удобной для него последовательности. Для этого необходимо установить курсор на заголовок закладки и, удерживая левую клавишу мыши, перетащить закладку в требуемое место.
Навигация осуществляется из главного окна МАС УТР (Рисунок 29).
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 29 – Главное окно МАС УТР
Доступ ко всем экранным формам осуществляется путем выбора соответствующих опций главного меню системы (Рисунок 30), а также через кнопки на
формах, в рамках выполнения определенных функциональных задач.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 30 – Опции главного меню системы
Опции главного меню системы:
­ «Управление» - позволяет управлять информацией по заявкам и ресурсам;
­ «Справочники» - предназначается для хранения всевозможной информации
по ресурсам, контрагентам, единицам измерения и т.п.;
­ «Мониторинг» - позволяет визуализировать созданные расписания по каждому из ресурсов, обеспечивает доступ к электронной карте, а также быстро
получить самую актуальную информацию по заявкам и ресурсам;
­ «Отчеты» - предназначается для мониторинга деятельности компании в целом;
­ «Администрирование» - используется для настройки разделения прав доступа для различных категорий пользователей, определения филиалов и задания
правил;
­ «Открытые формы» - позволяет изменять настройки интерфейса и просматривать все открытые формы;
­ «Настройки» – позволяет устанавливать величины, используемые по умолчанию;
­ «Помощь»- предоставляет информацию о функционале системы и о системе
в целом.
Описание кнопок и чек-боксов, используемых на большинстве форм,
приводится ниже.
­ Создать – позволяет вводить новую информацию (создать новую заявку,
контрагента и т.п.);
­ Скопировать – позволяет создать копию уже существующей формы (например, заявки);
­ Открыть – используется для того, чтобы открыть форму с уже введенными
данными (существующую форму заявки, контрагента);
­ Обновить – используется для актуализации данных;
­ Удалить – используется для удаления выделенного элемента;
­ Восстановить – в случае, если на форме проставлен флажок «Показывать
удаленные записи» с помощью этой кнопки можно восстановить выделенную удаленную запись;
­ Показывать удаленные – используется для просмотра удаленных заявок. Все
удаленные заявки помечены зачеркиванием и имеют более светлый цвет
шрифта.
­ Закрепить в центре - при отжатии кнопки форма будет отображаться в виде
отдельного окна, которое пользователь может расположить в том порядке, в
котором ему удобно.
На отдельных формах могут быть использованы специфические для данной формы кнопки, описание которых будет приведено в соответствующих
разделах. Кроме этого в системе предусмотрены «горячие клавиши».
На форме всех выпадающих списков расположены следующие пиктограммы, унифицированные в рамках МАС УТР:
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
­
­
­
­
­
(Выбрать) – выделенная запись подставляется в поле выбора;
(Обновить) – обновление данных выпадающего списка;
(Добавить)– вызов окна добавления новой записи соответствующего
справочника;
(Закрыть) – закрытие окна выпадающего списка.
3.3.2 Ввод новой заявки
Для ввода новой заявки необходимо выбрать опцию меню «Управление»
 «Заявки». В появившемся окне в верхней части экрана пользователю необходимо нажать кнопку «Создать», в результате чего откроется регистрационная
форма заявки (Рисунок 31).
Для перехода по полям используются «горячие» клавиши или мышь.
кнопка редактирования
Рисунок 31 – Окно регистрации новой заявки
Все поля заявки, за исключением полей «Номер заявки» и «Дата ввода заявки», будут пустыми. Поле «Номер заявки» формируется системой автоматически и является неизменяемым. Поля, обязательные для заполнения, помечены пиктограммой .
Дата ввода заявки соответствует дате и времени создания заявки. При
желании пользователь может скорректировать данные значения.
Поля «№ заявки вход», «№ и дата доверенности» предназначены для руч-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ного ввода входных и выходных данных по заявке. Поле «№ и дата доверенности» предназначено для ввода номера доверенности, выданной водителю на перевозку груза и дату ее выдачи. Поле «Юр. лицо заказчику» предназначено для
определения компании, имя которой будет фигурировать в документах выданных заказчику.
Проставленный флажок «Существует копия во внешней системе» означает, что сведения данной заявки переданы в систему 1С для проведения последующих бухгалтерских операций.
Проставленный флажок «Предполагаемая» означает, что заявка включается в мастер-план и ожидается, что она поступит в будущем периоде (к примеру, в силу заключенных долгосрочных договоров). Данная заявка будет планироваться также как и все остальные заявки.
Для облегчения ввода предполагаемых заявок в журнале заявок существует кнопка «В мастер-план», которая позволит создать копии уже существующих заявок с проставленной галочкой «Предполагаемая». Для этого необходимо в журнале заявок выделить требуемую заявку и нажать кнопку «В мастерплан». У созданных заявок поля «Запланированное время», «Предпочитаемое
время» и «Фактическое время» на вкладке «Операции» будут пустыми. В случае если необходимо создать несколько предполагаемых заявок, то следует нажать клавишу <ctrl>, выделить требуемые заявки, и далее нажать кнопку «В
мастер-план».
Для того чтобы ввести название заказчика, т.е. организации, которая сделала заказ, необходимо из выпадающего списка выбрать наименование заказчика. Если контрагент отсутствует в данном списке, то необходимо ввести данного заказчика в справочник «Организация» (подробнее об этом – в разделе 0).
Также для контрагента необходимо указать его географическое местоположение – локацию.
В случае необходимости отредактировать уже имеющуюся информацию
по контрагенту, необходимо нажать на знак многоточия (…) в поле «Заказчик»
(при условии, что в поле уже указано наименование организации).
Флажок в окне «Экспедитор» подразумевает, что заказчик является экспедитором. В случае если флажок не был проставлен, то организация, использующая АС УТР сама выступает в качестве экспедитора либо перевозчика.
Флажок «Экспедитор» в данном окне является редактируемым, помечается в
том случае, если в справочнике «Организации» был проставлен соответствующий флажок.
Данные, касающиеся детальных сведений по заявке, сгруппированы в
виде отдельных вкладок:
­ на вкладке «Сведения» содержится информация о параметрах заявки;
­ на вкладке «Операции» вводится информация о местах и времени погрузки /
разгрузки;
­ вкладка «Планирование» используется для вывода информации о ресурсах,
назначенных на данную заявку и указания предпочитаемых ресурсов;
­ на вкладке «Дополнительные сведения» содержится контактная информация
о перевозчиках и водителях;
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
­ на вкладке «Импортированные сведения» будет содержать какую-либо информацию только в случае, если данная заявка была импортирована из
внешнего файла;
­ на вкладке «Результат перевозки» отражена информация о внештатных ситуациях, возникших при перевозке.
3.3.3 Последовательность действий менеджера по обработке заявки
В данном разделе приводится описание последовательных действий менеджера для обработки конкретной заявки.
После получения заявки менеджер должен зарегистрировать ее в АСУ ТР.
Для этого менеджер открывает регистрационную форму новой заявки через опцию главного меню «Управление»  «Заявки», кнопка «Создать». Введя данные во все поля, обязательные для заполнения, менеджер сохраняет заявку
(кнопка «Сохранить» в верхней части регистрационной формы заявки).
Далее данные заявки проверяются и утверждаются нажатием кнопки
«Принято». Если пользователь заполнил не все обязательные поля, то кнопка
«Принято» будет неактивной.
После утверждения заявки менеджер приступает к планированию. При
планировании заявки в АС УТР менеджер может использовать два режима работы:
­ Автоматическое планирование (назначение заявки на ресурс осуществляется
подсистемой автоматического планирования самостоятельно;
­ Ручное планирование (например, в случае, если менеджера не устраивает
вариант планирования, который подобрала система, он может назначить более подходящий, по его мнению, ресурс вручную).
Для того чтобы запустить работу системы в автоматическом режиме необходимо нажать кнопку «Автоматическое планирование» в верхней части регистрационной формы заявки.
После того, как заявка запланирована (т.е. найден ресурс для осуществления перевозки груза) на вкладке «Планирование» будут указаны данные по выбранному прицепу, водителю и тягачу.
Для того чтобы запланировать заявку вручную диспетчеру необходимо
самому заполнить поля «Перевозчик», «Тягач», «Прицеп», «Водитель» на
вкладке «Планирование» регистрационной формы заявки.
После наступления запланированного времени начала выполнения заявки
менеджер отслеживает фактическое время выполнение заявки. Для этого в окне
регистрационной формы заявки на вкладке «Операции» менеджер отмечает
фактическое время начала и/или окончания соответствующей операции. Для
ускорения ввода фактического времени выполнения операции пользователь
может использовать кнопки «Фактическое начало» и «Фактическое окончание»
на вкладке «Операции» регистрационной формы заявки.
3.3.3.1 Работа в автоматическом режиме
Если менеджер использует автоматический режим планирования, то АС
УТР назначает оптимальный ресурс на заявку (водителя, прицеп и тягач). Вы-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
бор ресурсов осуществляется на основании анализа близости нахождения ресурсов от места и времени погрузки, а также путем сопоставления требований,
указанных в заявке (вес груза, требуемый тип прицепа и т.п.) с характеристиками самих ресурсов, данных о занятости ресурса и существующих группировках.
Система построена таким образом, что поиск лучшего варианта размещения заявки ведется непрерывно до момента начала выполнения заявки или до
момента, пока найденные ресурсы не будут зафиксированы.
При выборе режима автоматического планирования менеджер должен
выполнить следующую последовательность шагов:
1. Создать группировки, выбрав опцию главного меню «Управление» 
«Группы ресурсов - Заданные» таким образом, обозначив для системы, какой водитель, на каком тягаче и прицепе ездит.
2. Создать корректировки – то есть указать для каждого ресурса группировок
начальное местоположение.
3. Ввести новую заявку, заполнив все обязательные поля.
4. В регистрационной форме заявки нажать кнопку «Автоматическое планирование».
5. Подсистема автоматического планирования из введенных группировок автоматически выберет подходящую тройку (или двойку) и назначит заявку на
выбранные ресурсы. Менеджер не указывает никаких ресурсов на вкладке
«Планирование» вручную.
6. В случае если менеджер хочет зафиксировать выбранную тройку (двойку)
ресурсов на данную заявку (чтобы в случае перепланирования, если и будет
найден лучший вариант, результат первоначального планирования не изменился), то необходимо нажать кнопку «Зафиксировать ресурсы». В этом
случае запланированные ресурсы будут проставлены в полях вкладки «Планирование» и при дальнейшем поиске вариантов размещения заявок системой заявка не будет переброшена на какой-либо другой ресурс.
3.3.3.2 Работа в ручном режиме
Если менеджер использует «ручной» режим планирования, то приоритет
остается за ним, т.е. если менеджер указывает предпочитаемые ресурсы на
вкладке «Планирование», регистрационной формы заявки, то МАС УТР назначает заявку именно на те ресурсы (водителя, прицеп и тягач), которые указал
менеджер (прицеп может быть не указан).
При выборе режима «ручного» планирования менеджер должен выполнить следующую последовательность шагов:
1. Ввести новую заявку, заполнив все обязательные поля.
2. В регистрационной форме заявки на вкладке «Планирование» указать те ресурсы, которые будут исполнять данную заявку.
Если выбранный ресурс недоступен в планируемый период времени, то
заявка на него не назначается.
1. Указать для каждого ресурса его начальное местоположение.
2. Для новой заявки после ввода всех необходимых параметров заявки менед-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
жер должен в регистрационной форме заявки нажать кнопку «Автоматическое планирование».
3. Если же менеджер проводит корректировку варианта транспортного средства, подобранного системой автоматически, то кнопка «Автоматическое планирование» остается нажатой во время ввода предпочитаемых ресурсов, а по
завершении их ввода менеджер нажимает кнопку «Сохранить».
4. МАС УТР назначит указанные предпочитаемые ресурсы на заявку, если не
имеется никаких противоречий (ресурс уже назначен на выполнение другой
более выгодной заявки и т.п.).
3.4 Управление
3.4.1 Управление ресурсами
3.4.1.1 Мастер-план
Мастер-план предназначен для того, чтобы сравнивать план с фактом, а
именно сравнивать достижение запланированных показателей с показателями,
достигнутыми на текущий момент. Для того чтобы создать мастер-план, необходимо выбрать опцию меню «Управление»  «Мастер-планы», нажать кнопку «Создать» и в открывшемся окне выбрать требуемый период времени
(Рисунок 32). В результате высветится список заявок, которые были запланированы и у которых начало первой операции попадает в выбранный период времени. Как правило, на момент создания Мастер плана у всех заявок в данном
списке проставлена галочка «Предполагаемая», т.к. сначала предполагаемые
заявки вводятся, затем планируются, а затем уже создается документ «Мастер
план», который фиксирует расчетные значения на момент утверждения плана,
такие как Прибыль, Выручка, Километраж, Затраты на перевозку, Затраты на
простой, Затраты всего. После сохранения мастер - плана первоначальные
«расчетные» значения фиксируются и переносятся в верхнюю часть формы, а в
нижней же части формы отражаются текущие значения, которые были рассчитаны системой на текущий момент (Рисунок 33). В дальнейшем, при открытии
данного документа в любой момент пользователь может сравнить текущие показатели с запланированными и проконтролировать выполнение плана.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 32 – Мастер-план
Рисунок 33 – Отчет мастер-плана
3.4.1.2 Корректировки местоположения
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Для осуществления планирования необходимо указать местоположение
конкретного тягача, прицепа и водителя. Без указания начального местоположения подсистема автоматического планирования «не видит» ресурс. Местоположение ресурса задается документом «корректировки» местоположения.
Логика при вводе данных о начальном местоположении собственных и
привлеченных ресурсов компании несколько различается:
­ для собственных ресурсов компании корректировка местоположения задается обычно один раз, и в дальнейшем отслеживается системой автоматически.
­ для привлеченных ресурсов предусмотрена возможность неоднократного
ввода корректировок местоположения. Предполагается, что система не обладает полными данными о привлеченных ресурсах, их положение может
измениться без участия системы (привлеченный ресурс выполнял заявку
другой компании). Поэтому местоположение привлеченного ресурса считается актуальным лишь в течение 24 часов после выполнения им последней
заявки из списка заказов системы.
В системе предусмотрено три способа указания местоположения ресурса:
­ с помощью опции меню «Управление»  Корректировки местоположения
(Рисунок 34);
­ при помощи кнопки «Изменить текущее местонахождение» в карточке ресурса (местоположение задается отдельно для каждого из ресурсов водитель,
тягач, прицеп);
­ с помощью вкладки «Планирование» регистрационной формы заявки пользователь может одновременно создать корректировку местоположения для
«тройки» ресурсов (одновременно для водителя, прицепа и тягача) или
«двойки» ресурсов (водитель и тягач, без указания прицепа). Для этого надо
выбрать все необходимые ресурсы и нажать кнопку «Указать местонахождение». При этом открывается окно с документом «Новое перемещение», в
котором уже проставлены значения во всех полях, включая поля «Локация»
и «Дата и время», которые соответствует дате и времени первой погрузки
данной заявки.
­
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 34 – Корректировки местоположения
Визуально проследить перемещение водителя, прицепа и тягача можно с
помощью опции меню «Мониторинг». Данные могут быть представлены на
диаграмме
Гантта
(«Мониторинг»

«Расписание
водителей/тягачей/прицепов»), а также на карте («Мониторинг»  «Расположение тягачей»)
В случае если фактическое местоположение ресурса не совпадает с местоположением по данным системы (например, согласно значению адреса разгрузки, указанному в последней заявке, выполненной данным ресурсом, он
должен находиться в Казани, а фактически ресурс находится в Москве), менеджер должен указать в МАС УТР истинное местонахождение ресурсов. Для
этого менеджер должен создать новую запись, в которой и указать новую локацию (местонахождение ресурса). При нажатии кнопки «Создать» на экране
отобразится окно (Рисунок 35), в котором пользователь может ввести новое местоположение ресурса. При нажатии кнопки «Открыть» открывается окно уже
созданной корректировки.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 35 – Окно добавления корректировки местоположения
В случае если не установлен флажок «Обрабатывать при планировании»,
подсистема автоматического планирования не учитывает данный ресурс в процессе планирования. Такая запись будет выделена зеленым цветом.
3.4.1.3 Периоды недоступности
Данные документы создаются, чтобы менеджер мог указать, в какой период времени тот или иной ресурс недоступен, т.е. система не должна планировать заявки на данный ресурс. Для ввода информации о недоступности ресурса
используется опция меню «Управление Периоды недоступности (Рисунок
36).
При нажатии кнопки «Создать» на экране отобразится окно (Рисунок 37),
в котором пользователь может ввести новую запись о недоступности ресурса.
При нажатии кнопки «Открыть» открывается окно уже созданной недоступности.
В случае если не установлен флажок «Обрабатывать при планировании»,
то подсистема автоматического планирования не учитывает данную запись о
недоступности в процессе планирования. Такая запись будет выделена зеленым
цветом. Также в окне регистрации недоступности указываются причины недоступности конкретного ресурса. Периоды недоступности могут создаваться как
для тройки ресурсов, так и для каждого ресурса отдельно.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 36 – Периоды недоступности
Рисунок 37 – Окно добавления недоступности ресурса
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3.4.1.4 Регистрация транспорта стороннего перевозчика
Данный пункт меню предназначен для ведения сведений о ресурсах привлеченных перевозчиков. Для ввода информации о них используется опция меню «Управление»  «Регистрация транспорта стороннего перевозчика»
(Рисунок 38).
Рисунок 38 – Регистрация транспорта стороннего перевозчика
При нажатии кнопки «Создать» на экране отобразится окно (Рисунок 39),
в котором пользователь может ввести запись о новом стороннем перевозчике.
При нажатии кнопки «Открыть» открывается окно уже существующей записи.
Для сторонних ресурсов с помощью выпадающих списков указывается
следующая информация (Рисунок 39):
­ тип транспорта – указывается тип прицепа;
­ область местонахождения – обозначается зона предполагаемой погрузки
(область, штат и т.п.);
­ область направления – обозначается зона предполагаемой разгрузки (область, штат и т.п.);
­ организация – указывается наименование организации-перевозчика;
­ время начала и время окончания – указывается период, когда указанный ресурс доступен.
При осуществлении планирования подсистема автоматического планирования сопоставляет следующие параметры заявки и привлеченного транспорта:
­ дата и время выполнения заявки с периодом доступности ресурса;
­ адрес погрузки с областью нахождения ресурса;
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
­ адрес разгрузки с областью направления;
­ требуемый тип требуемого прицепа с указанным типом транспорта.
­
Рисунок 39 – Окно ввода сведений о привлеченном ресурсе
В результате сопоставления в разделе «Зарегистрированные перевозчики»
на вкладке «Планирование» (Рисунок 49) будут отражаться только ресурсы,
полностью удовлетворяющие параметрам заявки.
3.4.1.5 Группы ресурсов
Под группой понимают возможные приемлемые сочетания ресурсов (водителей, прицепов и тягачей), которые показывают, что в указанный промежуток времени данный водитель может быть назначен на определенный тягач и
прицеп. В группировке указывают устоявшиеся «тройки» (т.е. какой водитель,
на каком тягаче и прицепе ездит) или «двойки» (если указан только водитель и
тягач), а также период, в течение которого существование данной тройки
(двойки) актуально. Указывать все возможные сочетания водитель – прицеп –
тягач нецелесообразно.
Группировку ресурсов можно создать в окне «Управление»  «Группы
ресурсов – Заданные» » (Рисунок 40).
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 40 – Группы ресурсов - Заданные
При нажатии кнопки «Создать» на экране отобразится окно (Рисунок 41),
в котором пользователь может ввести запись о новом стороннем перевозчике.
При нажатии кнопки «Открыть» открывается окно редактирования уже существующей записи.
В случае если не установлен флажок «Обрабатывать при планировании»,
то подсистема автоматического планирования не учитывает данную группу ресурсов в процессе планирования. Такая запись будет выделена зеленым цветом.
Документ по группировке создается с указанием временного периода (т.е.
указываются даты, когда конкретный водитель может ездить на конкретном
грузовике и прицепе).
Отслеживать актуальные группы ресурсов (т.е. действующие на текущий
момент времени) можно в окне «Управление»  «Группы ресурсов - Текущие»
(Рисунок 42).
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 41 – Окно регистрации группы ресурсов
Рисунок 42 – Группы ресурсов - Текущие
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Для удобства пользователя в окне «Группы ресурсов - Текущие» помимо
основных кнопок используются специальные кнопки:
­ кнопка «Прекратить» используется для того, чтобы указать текущие дату и
время в качестве времени окончания действия выделенной группировки;
­ кнопка «Перегруппировать» используется для открытия формы ускоренного
ввода изменений в группу (Рисунок 43). В результате выбранная группировка будет закрыта текущей датой, а в появившемся окне будет сформирована
новая группа, при этом дата начала будет соответствовать текущей дате, ресурсы по умолчанию будут также проставлены. Менеджер должен будет изменить только требуемый ресурс и указать дату окончания новой группировки.
­
Рисунок 43 – Окно перегруппировки ресурсов
3.4.2 Управление заявками
3.4.2.1 Просмотр списка заявок
Для отображения всех заявок необходимо выбрать опцию меню «Управление»  «Заявки». По каждой заявке отображается информация, позволяющая
менеджеру осуществлять мониторинг всего списка заявок (Рисунок 44).
В верхней части окна предусмотрена строка быстрого поиска. Поиск
осуществляется по всем полям, как по полному, так и частичному введенному
слову. На экране будут отражаться записи, соответствующие условиям поиска.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
В окне реализована фильтрация по всем полям: под табличным заголовком находятся поля, в которые пользователь должен ввести требуемые соответствующие значения. В результате отобразится список релевантных данных. Для
большинства полей реализована возможность настраивать фильтр.
Отфильтровать заявки можно также с помощью Фильтра по дате заявки.
Для этого необходимо нажать кнопку
в верхней части окна и затем выбрать
требуемый период поступления заявок.
На форме «Управление заявками» указана обобщенная информация по
следующим полям:
­ Номер заявки – указывается номер заявки, формируемый системой автоматически;
­ Дата заявки - указывается дата регистрация заявки;
­ Статус заявки – позволяет отслеживать текущее состояние заявки;
­ Заказчик – указывается краткое наименование заказчика;
­ Дата загрузки – указывается дата и время первой загрузки;
­ Место загрузки – указывается только наименование города загрузки;
­ Дата разгрузки – указывается дата и время последней разгрузки;
­ Место разгрузки – указывается только наименование города разгрузки;
­ Перевозчик – указывается наименование перевозчика, осуществляющего перевозку;
­ Водитель – указывается фамилия, имя, отчество водителя, выполняющего
заявку;
­ Модель – указывается наименование модели тягача;
­ Номер тягача – указывается гос. номер регистрации тягача;
­ Тип прицепа – указывается тип прицепа;
­ Номер прицепа – указывается гос. номер регистрации прицепа;
­ Офис – наименование офиса менеджера, который или внес заявку в систему,
или внес последние изменения в регистрационной форме заявки;
­ Менеджер – указывается логин менеджера, внесшего последние изменения в
заявку;
­ Стоимость от заказчика – указывается стоимость заявки;
­ Стоимость перевозчику – указывается величина стоимости, выплачиваемой
перевозчику за выполнение заявки;
­ Передано – наличие данного флажка означает, что сведения по заявке переданы в систему 1С.
Первые пять столбцов («Номер заявки», «Дата заявки», «Статус заявки»,
«Заказчик», «Дата загрузки») закреплены и, при перемещении горизонтального
скроля вправо, всегда видны пользователю. Также пользователь может настраивать порядок столбцов, для чего необходимо, удерживая мышкой заголовок поля, перенести столбец в требуемое место.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 44 – Управление заявками
Кроме этого, в системе предусмотрена возможность настраивания конкретным пользователем «под себя» списка и порядка столбцов в форме управление заявками.
­ Чтобы скрыть столбец, надо установить мышку на заголовок соответствующего столбца  правая клавиша  выбрать пункт меню «Скрывать эту колонку»  столбец будет скрыт.
­ Чтобы отобразить столбец: установить мышку на заголовок любого столбца
 правая клавиша  настройка колонок  в отобразившемся окошке будет
список скрытых столбцов. Выбирается тот столбец, который необходимо
восстановить, затем правая клавиши мыши  выбрать пункт меню «Показывать эту колонку»  столбец будет восстановлен.
Пользователь может увидеть удаленные заявки, для чего необходимо нажать кнопку «Показывать удаленные». Все удаленные заявки помечены на экране зачеркиванием и имеют более светлый цвет шрифта. При открытии регистрационной формы удаленной заявки можно просмотреть все данные, однако
их редактирование недоступно.
Помимо основных кнопок («Создать», «Открыть», «Удалить», «Обновить», «Показывать удаленные», «Закрепить в центре») в верхней части окна
имеются следующие кнопки:
­ Восстановить – данная кнопка используется для восстановления удаленных
данных, поэтому она становится активной только при выделении удаленной
ранее заявки;
­ В мастер – план – используется для копирования заявок в мастер-план;
­ Печать – при нажатии на данную кнопку вызывается окно с параметрами
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
­
­
­
­
печати. Позволяет распечатать список заявок;
Экспорт – с помощью данной кнопки реализована возможность экспорта
списка заявок в MS Excel;
Реверсивная загрузка – данная кнопка предназначена для того, чтобы вновь
поступающие заявки появлялись в начале списка всех заявок;
Загрузить все - при помощи данной кнопки можно загрузить весь список
заявок, введенных в систему;
Остановить – при помощи данной кнопки можно остановить процесс загрузки всех заявок в систему.
3.4.2.2 Статусы заявок
Для отображения статуса заявки приняты следующие цветовые обозначения:
­ светло-желтый цвет – не утвержденная заявка или импортированная. В системе предусмотрена возможность импорта заявок из внешних файлов (из
файлов MS Excel, текстовых файлов формата .rtf);
­ светло-зеленый цвет – утвержденная заявка;
­ голубой цвет – заявка выполняется;
­ светло - розовый цвет – запланировано не в срок (т.е. запланированное время
выполнения заявки не соответствует предпочитаемому времени)
­ розовый цвет - заявка находится в процессе планирования (В обработке).
Такие статусы заявки как «запланированная», «закрытая», «выполненная», «отмененная» специально цветом не выделяются. Наличие цвета у заявки
означает, что менеджер должен обратить внимание на данную заявку, и, в случае необходимости, проконтролировать ее выполнение.
После открытия и сохранения регистрационной формы новой заявки она
будет иметь состояние «Неутвержденная» и отображаться светло-желтым цветом в списке заявок. Если заявка импортирована из внешнего файла, то она
также будет окрашена в светло-желтый цвет, и будет иметь статус «Импортированная».
Пользователь заполняет все обязательные поля. Для сохранения введенных изменений необходимо нажать кнопку «Сохранить».
После ввода всех обязательных к заполнению полей и уточненных данных по заявке менеджер нажимает кнопку «Принято». В результате изменится
статус заявки с «Неутвержденная» на «Утвержденная». Данный статус заявки
можно увидеть в окне «Управление заявками» (Рисунок 44), кроме того, цвет
заявки также изменится на светло-зеленый.
После нажатия кнопки «Автоматическое планирование» в верхней части
регистрационной формы статус заявки изменится с «Утвержденная» на «В обработке».
После того, как заявка запланирована (т.е. найден ресурс для осуществления перевозки груза), статус заявки изменится на «Запланированная», а во
вкладке «Планирование» (Рисунок 49) будут указаны данные по выбранному
прицепу, водителю и тягачу.
После наступления запланированного времени начала выполнения заявки
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
менеджер отслеживает и проставляет фактическое время выполнение заявки.
Статус «Выполняется» заявка приобретает, когда проставлено фактическое время начала первой операции заявки и данная заявка была запланирована.
Статус «Выполненная» – когда данная заявка была запланирована и проставлено время окончания последней операции заявки.
В Таблица 4 приведены основные условия и действия, приводящие к изменению статуса заявок.
№
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Таблица 4 – Статусы заявок
Статус заявки
Необходимые условия
Цвет заявки
Неутвержденная Не все обязательные поля в регистра- светлоили Импортиро- ционной форме заявки заполнены желтый
ванная
и/или кнопка "Принято" не включена
Утвержденная
Включена кнопка "Принято"
светло-зеленая
В обработке
Включена кнопка "Автоматическое
планирование", подсистема автоматического планирования осуществляет поиск оптимальных ресурсов
Запланированная В регистрационной форме заявки на
вкладке "Планирование" в разделе
"Транспортное средство" заполнены
поля ресурсов
Выполняется
Проставлено фактическое время начала первой операции заявки и заявка
была запланирована
Выполненная
Проставлено фактическое время
окончания последней операции заявки и заявка была запланирована
Закрытая
Проставлено фактическое время
окончания последней операции заявки и № и дата ТТН
Запланировано не Заявка запланирована, но запланиров срок
ванное время выполнения какой-либо
операции не совпадает с предпочитаемым временем
Удаленная
Заявка была удалена из регистрационной формы заявок
Отмененная
Заявка была отменена
3.4.2.3 Вкладка « Общие сведения»
розовый
нет цвета
голубой
нет цвета
нет цвета
светлорозовый
светло-серый
цвет, сама заявка зачеркнута
нет цвета
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Данные, касающиеся детальных сведений по заявке, указываются на
вкладке «Общие сведения» (Рисунок 45).
­ Раздел «Свойства» содержит детальные сведения о заявке:
 выпадающий список «Валюта» предназначен для выбора наименования
валюты, в которой будет осуществлен расчет по заявке (рубль, доллар
США или евро);
 поле «Курс валюты» применяется для указания курса, по которому будет
осуществлен перерасчет в рублевом эквиваленте (по умолчанию указывается единица (1), соответствующая одному рублю). Поле обязательно для
заполнения;
 поле «Стоимость от заказчика» является также обязательным. Данная
информация в дальнейшем используется для расчета величины в поле
«Доход» на вкладке «Планирование» как по каждой заявке, так и для получения агрегированных данных при расчете коэффициентов эффективности по деятельности компании за определенный период. Значение в
поле «Стоимость от заказчика» может быть рассчитано с учетом НДС
(18%). При этом первоначальные значения пересчитываются автоматически в зависимости от величины НДС и выводятся в третьем поле рядом
со ставкой НДС;
 выпадающий список «Форма оплаты заказчика» используется для указания формы оплаты (наличная/безналичная) при проведении расчетов с
заказчиком;
 поле «Средняя стоимость по стране» предназначено для указания средней
стоимости топлива по стране; в поле «Топливный сбор» указывается дополнительный сбор за топливо в случае повышения его стоимости (используется при необходимости);
 Поле «Единица длины» предназначено для того, чтобы определить в каких единицах измерения будут в дальнейшем указаны параметры груза
(длина, ширина, высота);
 Поле «Единица веса» предназначено для того, чтобы определить в каких
единицах измерения будет определен вес груза;
 флажки «Страховка груза», «Наличие страховой ответственности перевозчика», «Страхование ответственности заказчика» предназначены для
учета информации о страховании груза;
 флажок «Обратная загрузка» используется в качестве справочной информации;
 Поле «Требования заказчика» предназначено для ввода комментариев по
каждой конкретной заявке. Если проставлено наименование организации
заказчика, то в данном поле автоматически прописываются требования,
указанные на карточке данной организации, для каждой конкретной заявки менеджер может скорректировать формулировку требований.
­ В раздел «Междугородняя / Международная» вводится информация, если
заявка является международной:
 в текстовые поля «Таможня грузополучателя» и «Таможня грузоотправителя» вносятся сведения о наименовании таможен;
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
 в поле «Особые условия» вводится дополнительная текстовая информация.
­ Раздел «Сведения для перевозчика» содержит подробную информацию о перевозимом грузе. Для того, чтобы ввести новый груз необходимо нажать
кнопку «Добавить» в нижней части окна (Рисунок 46). В открывшемся окне
заполнить следующие поля:
 в подразделе «Общие сведения» указать «№ заявки у заказчика» (номер
заявки, который уже был присвоен заказчиком для данной заявки) и
«Плотность» (плотность перевозимого груза);
 в подразделе «Упаковка» в поле «Кол-во» определить количество упаковочных единиц, в поле «Ед» указать их тип (к примеру, 10 палеток), в поле «Тип» указать тип упаковки (к примеру, палетки);
 в подразделе «Общий вес» указать вес всего груза «Нетто» (без упаковки)
и «Брутто» (с упаковкой);
 в подразделе «Размеры» пользователь должен указать размеры всего перевозимого груза, а именно его длину, ширину, высоту и объем;
 в подразделе «Содержимое» в поле «Кол-во» определить кол-во единиц
товара в одной упаковке (к примеру, в одной палетке 20 бутылок молока),
в поле «Тип» - указать тип самого груза («молоко»), далее в поле «Единицы» - указать (к примеру, «бутылки»), «Вес единицы» - указать вес одной бутылки и в поле «Стоимость единицы» - стоимость одной бутылки;
 в подразделе «Сведения об опасных материалах» пользователь может
указать дополнительную информацию об опасности перевозимого груза;
 в подразделе «Дополнительная информация» пользователь может указать
дополнительную информацию о перевозимом грузе.
Кнопки «Добавить», «Изменить», «Удалить» используются для создания,
изменения и удаления различных грузов.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 45 – Вкладка « Общие сведения»
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 46 – Регистрационная форма груза
Пользователь также может задавать собственные настройки. В данном
случае при открытии регистрационной формы новой заявки в выпадающих
списках (требуемый тип прицепа, грузоподъемность, объем и пр.) по умолчанию будут проставлены заданные значения. Подробнее данная функциональность прописана в разделе «Администрирование».
3.4.2.4 Вкладка «Операции»
В рамках одной заявки может фигурировать несколько адресов погрузки
и разгрузки. В рамках каждого адреса могут осуществляться следующие действия: перемещение, погрузка, подготовка, разгрузка, стоянка. Все эти действия
отражены на данной вкладке. Для обозначения данных понятий используется
вкладка "Операция" регистрационной формы заявки (Рисунок 47). Добавить
новую операцию можно следующими способами:
­ используя кнопку «Добавить» на вкладке «Операции» формы редактирования заявки, при нажатии которой открывается окно редактирования операции;
­ используя поля ускоренного ввода операций на вкладке «Операции».
1. В первом случае в появившемся окне редактирования операции (Рисунок 47)
необходимо указать следующие данные:
­ тип операции. В зависимости от выбранного типа (погрузка, порожний переезд, разгрузка, транспортировка, или стоянка) активны будут те поля, которые относятся непосредственно к выбранному типу операции. Например,
если выбрана операция "Разгрузка", то поля "Грузоотправитель", и "Адрес
отправителя" будут недоступны, так как данные поля относятся к другому
типу операций («Погрузка»).
­ Грузоотправитель/грузополучатель (поля активны, если выбрана операция
«Погрузка»/ «Разгрузка» соответственно). Для ввода значений грузоотправителей / грузополучателей необходимо в окне выпадающего списка выбрать требуемого контрагента. Если контрагент отсутствует, то менеджер
может ввести новую запись, либо через опцию меню («Справочники» 
«Организации»), либо через кнопку «Добавить» в окне выпадающего списка.
Новое значение автоматически будет проставлено в поле «Грузоотправитель
/ Грузополучатель». Следует отметить, что в выпадающем списке будут высвечиваться только те организации, которые были отмечены как «Грузоотправитель»/»Грузополучатель» соответственно в карточке организации.
­ Пункт отправления/назначения, Город отправления/назначения. Для того
чтобы ввести пункт отправления/назначения, следует в соответствующем
поле с выпадающим списком указать необходимый адрес. Если в выпадающем списке необходимый адрес отсутствует, то следует внести этот адрес в
справочник локаций, перейдя в него непосредственно через опцию меню
«Справочники»  «Локации» (Рисунок 67) или на вкладке «Локации» в регистрационном окне соответствующего контрагента (Рисунок 67).
­ Километраж, км. указывается автоматически при автоматическом планировании.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
­ Длительность каждой конкретной операции (погрузки, разгрузки и т.п.) указывается в поле «Длительность, мин.».
­ Предпочитаемое и фактическое время начала/окончания выполнения операции. В полях «Предпочитаемое время начала»/ «Предпочитаемое время
окончания» указывается время, к которому необходимо начать / закончить
операцию по требованию заказчика. Поля «Фактическое время начала»/
«Фактическое время окончания» используются для отслеживания менеджером момента непосредственного начала/окончания выполнения операции.
­ Комментарий (в случае необходимости).
2. Ускоренный ввод операций осуществляется с помощью полей «Организация», «Адрес», «Предпочитаемое время начала», «Длительность», расположенных в нижней части экрана. В поле «Организация» по умолчанию проставляется то же значение, что и в поле «Заказчик» (при необходимости
пользователь может изменить значение в поле «Организация»). Значения в
поле «Длительность» проставляются автоматически на основании данных,
указанных в карточке выбранной организации («Справочник»  «Организации»  поле «Нормативное время»); в выпадающем списке «Адрес» указываются все локации, закрепленные за данной организацией. После указания
всех данных, пользователь указывает тип операции (Погрузка или Разгрузка), нажимая кнопку «Погрузка» или «Разгрузка». Введенные сведения автоматически будут отображены в соответствующих колонках.
Временные данные считаются указанными корректно в следующих случаях:
­ Заполнено только поле «Длительность» для всех операций погрузки/разгрузки (при этом заявка будет планироваться на самое раннее время,
которое возможно);
­ Заполнены поля «Предпочитаемое время начала» и «Предпочитаемое время
окончания»;
­ Заполнены поля «Предпочитаемое время начала» и «Длительность»;
­ Заполнены поля «Предпочитаемое время окончания» и «Длительность».
­
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 47 – Добавление новой операции
Для редактирования ранее введенной информации по какой-либо операции необходимо нажать на кнопку «Открыть», в этом случае будет открыто окно (Рисунок 47) с уже введенными данными. Для сохранения отредактированных данных необходимо нажать на кнопку «Сохранить».
Для удаления введенной операции используется кнопка «Удалить». Удаленная операция будет помечена флажком в столбце «Закрыт» табличной части
вкладки «Операции». Таким образом, пользователь видит все свои действия с
операциями и при желании может их скорректировать. Однако, после того как
пользователь сохранит заявку (а, следовательно, и все введенные изменения)
удаленные операции отображаться не будут.
Кнопки «Вверх» и «Вниз» предназначены для указания порядка операций. Учитывая логику бизнес-процесса, первой должна стоять операция «Погрузка». В системе осуществляется контроль последовательности ввода типов
операций. В случае если, например, пользователь сначала ввел данные по операции «Разгрузка», необходимо переместить эту операцию ниже. Если последовательность нарушена, то кнопки «Принято» и «Автоматическое планирование» будут неактивны.
В системе осуществляется проверка правильности ввода дат:
­ если операция является первой в последовательности, то ее окончание
должно быть раньше даты начала последующей операции;
­ если операция является последней, то дата ее начала должна быть позже даты окончания предыдущей операции;
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
­ если операция является промежуточной (т.е. есть предшествующая и последующая операции), то осуществляется двойная проверка: во-первых, начало
операции должно быть позже даты окончания предыдущей операции и, вовторых, окончание операции должно быть раньше начала последующей операции.
Если время и последовательность заданы некорректно, то соответствующая операция выделяется розовым цветом (Рисунок 48).
Рисунок 48 – Регистрационное окно заявки с некорректно введенными
операциями (время выполнения второй операции раньше, чем время выполнения первой)
Для указания времени начала и окончания операции используются колонки «Предпочитаемое время», «Фактическое время» и «Запланированное
время» (Рисунок 48). Колонка «Фактическое время» (столбцы «Начало» и «Конец») является аналогом полей «Фактическое время начала» / «Фактическое
время окончания» формы редактирования операции. В колонке «Запланированное время» указывается время начала/окончания данной операции согласно
данным подсистемы автоматического планирования. Значения в поля «Фактическое время: начало» и «Фактическое время: конец» могут вводиться из окна
каждой операции (поля «Фактическое время начала/окончания»), или с помощью опций выпадающего меню кнопок «Фактическое начало» и «Фактическое
окончание», что позволяет значительно сократить время ввода данных. В качестве фактического времени из выпадающего меню может быть выбрано:
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
­ предпочитаемое время – вводится дата и время, совпадающее по значению с
данными в колонке «Предпочитаемое время»;
­ текущее время – вводится дата и время, совпадающее по значению с текущим моментом времени;
­ планируемое время – вводится дата и время, совпадающее по значению с
данными в колонке «Запланированное время».
3.4.2.5 Вкладка «Планирование»
Результаты автоматического планирования будут указаны на вкладке
«Планирование» (данные по выбранному прицепу, водителю и тягачу)
(Рисунок 49).
В разделе «Ближайшие свободные ресурсы» указаны ресурсы, которые
будут свободны к началу выполнения первой операции заявки. Ресурсы расположены по мере удаленности от места выполнения первой операции. В колонке
«Местоположение» указано последнее местоположение ресурсов, зафиксированное системой.
В разделе «Запланированные состояния выбранных ресурсов» указаны
дата начала/ окончания уже запланированных на данный ресурс операций. Эти
разделы помогают пользователю наглядно увидеть доступные для выполнения
заявки ресурсы.
Также на вкладке «Планирование» отображается информация о величине
прибыли (поле «Доход»). Данное поле рассчитывается следующим образом:
Значение поля «Стоимость от заказчика» – Значение поля «Стоимость перевозчику» (Рисунок 49). Таким образом, менеджер может видеть величину дохода
от каждой конкретной заявки. Поле «Юр. лицо перевозчику» предназначено
для обозначения имени юр. лица, которое будет фигурировать в документах
выдаваемых перевозчику. Поле «Форма оплаты перевозчику» применяется для
указания наличной или безналичной формы оплаты расчетов с перевозчиком. В
поле «Рыночная стоимость» указывается средняя рыночная стоимость подобной заявки.
На вкладке «Планирование» менеджер может указать либо каждый из
трех ресурсов отдельно, (заполнив поля “Водитель “Тягач” и “Прицеп”) либо
(если на них была заведена группировка) проставить все ресурсы одновременно. Это осуществляется следующим образом: в разделе «Запланированные состояния выбранных ресурсов» отображаются группировки, в которых фигурирует любой из указанных ресурсов. Если такая группировка одна, то при двойном щелчке по строке группировки все ресурсы, входящие в нее, автоматически будут проставлены в соответствующие поля. Если таких групп несколько,
то отображаются все существующие наборы ресурсов и менеджер осуществляет выбор наиболее подходящего из них.
Также в данном разделе помимо группировок указано местоположение
каждого ресурса после выполнения последней заявки (столбец «Начальное местоположение»), что позволяет менеджеру видеть, находятся ли ресурсы в одном или разных местах.
После того, как заявка запланирована на выбранные ресурсы, сведения о
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
них проставляются в поля «Тягач», «Прицеп», «Водитель».
Менеджер может просмотреть подробное объяснение результатов планирования двумя способами:
­ в окне логов переговоров подсистемы автоматического планирования
(Рисунок 50), где приводится информация по всем заявкам Системы. Чтобы
различать переговоры, относящиеся к разным заявкам, используется цветовая подсветка;
­ непосредственно в нижней части окна конкретной заявки (Рисунок 49) на
вкладке «Дополнительные сведения». На данной панели отображаются переговоры подсистемы автоматического планирования по конкретной заявке.
Ресурсы,
указанные
менеджером
Указывается справочная информация по сторонним перевозчикам, доступным в требуемый период на требуемом направлении
1.Список
группировок.
Менеджер может выбрать
подходящую.
2.Указывается местоположение ресурса
Рисунок 49 – Регистрационная форма заявки (вкладка «Планирование»)
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 50 – Лог переговоров
3.4.2.6 Вкладка «ТТН»
На данной вкладке отражаются все данные касательно ТТН. Пользователь
может создавать ТТН для каждой операции заявки, для этого ему необходимо в
нижней части окна заполнить поля «Номер ТТН», «Дата создания ТТН», «Операция» и после этого нажать кнопку «Создать». В случае если необходимо закрыть ТТН, пользователю следует выделить требуемый ТТН из списка, заполнить поле «Дата закрытия ТТН» и нажать кнопку «Закрыть ТТН» (Рисунок 51).
При выборе конкретного ТТН, все данные относительно него отражаются в
нижней части окна, пользователь может их отредактировать, просто изменив
отображенные данные, после нажать кнопку «Редактировать». В результате отредактированные данные будут отражены в списке ТТН.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 51 – Вкладка «ТТН»
3.4.3 Справочники
В системе предусмотрено ведение двух типов справочников (Рисунок 52):
­ основные справочники, в которых содержатся данные основных объектов
МАС УТР (контрагенты, транспортные ресурсы, водители, локации и пр.);
­ справочники атрибутов, в которых указаны значения свойств объектов основных справочников.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 52 – Справочники МАС УТР
3.4.3.1 Основные справочники
В основных справочниках содержится информация по следующим объектам:
­ водители;
­ тягачи;
­ прицепы;
­ организации;
­ города;
­ локации.
Все основные справочники выполнены в едином стиле: по каждому типу
приводится информация в форме таблицы, позволяющей пользователю видеть
общие сведения, а также общее количество записей в справочнике (Рисунок 54,
Рисунок 57, Рисунок 60, Рисунок 65, Рисунок 67).
В справочниках городов и локаций, помимо табличного представления
сведений, с помощью карты указывается географическое местонахождение выбранного пункта (Рисунок 65, Рисунок 67). В справочнике тягачей помимо данных, представленных в табличной форме также можно просмотреть на карте
все выполненные маршруты и пункты местонахождения выбранного тягача за
определенный период времени.
Для ускорения поиска записей во всех основных справочниках используется строка быстрого поиска. Поиск осуществляется по всем полям, как по
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
полному, так и частично введенному слову. На экране будут отражаться записи,
соответствующие условиям поиска (Рисунок 53).
Рисунок 53 – Быстрый поиск в справочнике водителей
Для того чтобы отредактировать требуемую запись, необходимо установить на нее курсор мыши и дважды кликнуть левой клавишей. В результате открывается окно, содержащее детальную информацию по интересующей записи
(Рисунок 56, Рисунок 61, Рисунок 63). В данном окне можно осуществлять редактирование сведений.
На формах редактирования записей в основных справочниках обязательные для заполнения поля отмечены пиктограммой
. Для некоторых полей
предусмотрен режим маски (шаблон), включить который можно, установив
флажок «Использовать маску», что облегчает ввод информации и позволяет избежать ошибок (например, употребления в регистрационном номере автомобиля букв, не используемых при регистрации).
На формах редактирования записей в основных справочниках (карточка
организации, карточка водителя, карточка прицепа и т.п.) имеется кнопка «Сохранить и закрыть», нажатие на которую приводит к закрытию соответствующей формы с автоматическим сохранением всех сделанных изменений.
Кнопка-флажок «Неполный контроль состояний» на карточке водителя,
прицепа и тягача используется для обозначения привлеченных ресурсов. Установленный флажок означает, что по истечении 24 часов с того момента, как
данный ресурс выполнил последнюю заявку, его местонахождение не учитыва-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ется подсистемой автоматического планирования при планировании последующих заявок.
3.4.3.2 Справочник «Водители»
Справочник «Водители» (Рисунок 54 – Рисунок 56) используется для
хранения информации обо всех водителях (фамилия, имя, отчество, телефон и
т.п). Для некоторых полей можно использовать режим маски, установив флажок «Использовать маску», что позволяет унифицировать вводимые сведения
(Рисунок 56):
­ для поля «Телефон» используется следующая маска: первые три цифры
предназначены для ввода кода страны, вторые три (четыре) цифры – для
ввода кода города, последние шесть (семь) собственно номер;
­ для поля «Водительское удостоверение» используется следующая маска:
первые два символа – числа, затем два символа – буквенное обозначение и
последующие шесть - цифры;
­ для поля «Паспорт» используется следующая маска: серия, номер, кем и когда выдан.
Если вводимые данные не соответствуют шаблону, то рядом с полем высвечивается значок . В поле справа от поля «Паспорт» пользователь может
выбрать страну, в которой был выдан паспорт. Это связано с тем, что в разных
странах разный формат ввода паспортных данных.
В справочнике (Рисунок 54 – Рисунок 56) необходимо указать организацию, к которой прикреплен водитель. Для задания организации необходимо
выбрать ее из выпадающего списка в поле «Владелец» (Рисунок 56). В данном
списке указаны все организации, которые содержатся в справочнике «Организации» (Рисунок 62). В случае если Водитель был проверен Службой Безопасности, то необходимо заполнить поля «Дата проверки» и «Результат проверки».
Таким образом, пользователь может просматривать результат в общем списке
водителей.
Для внесения водителя в черный список необходимо установить соответствующий флажок в поле “В черном списке” регистрационной формы конкретного водителя.
Удалить запись справочника можно либо из формы управления водителями (Рисунок 42), нажав на кнопку «Удалить», либо с помощью флажка «Закрыт» (Рисунок 56) в карточке конкретного водителя. Удаленная запись на экране не отображается. При желании пользователь может просмотреть все записи, включая и удаленные. Для этого необходимо установить флажок «Показывать удаленных водителей». Удаленная запись зачеркнута и помечена светлосерым цветом (Рисунок 42). Удаленную запись можно восстановить, для чего
требуется выделить запись и нажать на кнопку «Восстановить».
В нижней части карточки водителя в табличном виде представлена информация о данном водителе (группировки, начальное местоположение, периоды недоступности и список заявок, которые выполнял данный водитель).
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 54 – Справочник «Водители»
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 55 – Список водителей, включая удаленные записи
Рисунок 56 – Данные конкретного водителя
3.4.3.3 Справочник «Тягачи»
В справочнике «Тягачи» (Рисунок 57 – Рисунок 59) необходимо указать,
за кем из контрагентов данный тягач закреплен. В справочнике также предусмотрен быстрый поиск. Как и в справочнике водителей можно просмотреть
удаленные записи (флажок «Показать удаленные тягачи»), так и восстановить
их при необходимости.
В карточке конкретного тягача (Рисунок 58) указывается вся основная
информация о тягаче, модель, гос. номер, максимально перевозимый вес и т.п.
Более того, можно установить для конкретного тягача стоимость пробега за 100
км в зависимости от его особенностей, а также затраты от простоя данного тягача.
­ Для некоторых полей можно использовать режим маски, установив флажок
«Использовать маску», что позволяет унифицировать вводимые сведения
(Рисунок 58):
­ для поля «Гос номер» используемый шаблон: первая заглавная буква, потом
три числовых символа, затем две заглавные буквы, потом в скобках два символа, показывающих код региона;
­ для поля «Свидетельство о регистрации» используемый шаблон: серия, номер, когда выдан.
Принадлежность указывается с помощью выпадающего списка в поле
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
«Владелец». Если требуемая организация отсутствует в базе данных, менеджер
имеет возможность ввода новой организации непосредственно из карточки тягача.
В нижней части формы в табличном виде представлена информация о
данном тягаче (группировки, начальное местоположение, периоды недоступности и список заявок, которые выполнял данный тягач).
Кроме того, в карточке тягача имеется вкладка «Месторасположение», на
которой показан путь перемещения данного тягача (Рисунок 59). В данном окне
необходимо указать период движения данного тягача. При нажатии на кнопку
«Отобразить маршрут» строится траектория передвижения тягача за определенный период. Пиктограмма «Серый грузовик» используется для отражения
фактического местоположения тягача, пиктограммой «Синий грузовик» отображается операция погрузки, пиктограммой «Зеленый грузовик» - операция
разгрузки.
Рисунок 57 – Справочник «Тягачи»
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
настраиваемая
фильтрация
Рисунок 58 – Данные конкретного тягача
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 59 – Маршрут движения конкретного тягача
3.4.3.4 Справочник «Прицепы»
В справочнике «Прицепы» (Рисунок 60 – Рисунок 61) также необходимо
задать принадлежность прицепа к какому-либо перевозчику с помощью выпадающего списка «Организации» в поле «Владелец» (Рисунок 62). На карточке
конкретного прицепа (Рисунок 61) указывается гос. номер, тип прицепа, объем,
грузоподъемность вес и т.п. Для некоторых полей предусмотрен режим маски,
включить который можно, установив флажок «Использовать маску»:
­ для поля «Гос номер» используемый шаблон: первая заглавная буква, потом
три числовых символа, затем две заглавные буквы, потом в скобках два символа, показывающих код региона;
­ для поля «Свидетельство о регистрации»: используемый шаблон: серия, номер, когда выдан.
Большая часть значений атрибутов прицепа выбирается из выпадающего
списка (тип загрузки, грузоподъемность, объем, тип прицепа). Если требуемое
значение отсутствует в списке, то пользователь может ввести необходимые
значения двумя способами:
­ нажатием кнопки «Создать» в окне прицепы;
­ непосредственно в окне выпадающего списка необходимо нажать на пиктограмму «Добавить», что приведет к открытию новой регистрационной формы соответствующего параметра справочника (Рисунок 61).
­
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 60 – Справочник «Прицепы»
Нажатие на пиктограмму «Добавить» приведет к открытию соответствующего справочника
ат-
рибутов
Рисунок 61 – Данные конкретного прицепа.
В этом же окне возможно добавление нового значения атрибута.
В карточке каждого конкретного ресурса (водителя, прицепа и тягача) в
нижней табличной части можно увидеть историю по заявкам, которые были запланированы на данный ресурс. В таблице реализована сортировка (при нажатии на заголовок колонки показывается варианты сортировки) и фильтрация
(пользователь может настраивать фильтр – Рисунок 61).
3.4.3.5 Справочник «Организации»
Справочник "Организации" может быть открыт с помощью опции меню
"Справочники"  "Организации".
Для отслеживания данных по заказчикам, грузоотправителям, грузополучателям и перевозчикам используется единая база данных по контрагентам, поскольку одна и та же организация может быть представлена различными типами (например, компания может быть и заказчиком, и перевозчиком одновременно).
Добавить нового контрагента можно несколькими способами:
1. Через опцию меню «Справочники»  «Организации»: на экране отобразится справочник (Рисунок 62), после нажатия на кнопку «Создать» откроется
окно регистрационной формы, в которой необходимо указать все требуемые
сведения.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
2. На регистрационной форме заявки в поле «Заказчик», при условии, что значение не выбрано, нажать на знак многоточия (…), в результате откроется
регистрационная форма новой организации.
3. На регистрационной форме заявки в поле «Заказчик» в окне выпадающего
списка нажать на кнопку «Добавить…», в результате чего откроется карточка новой организации. В данном окне необходимо ввести наименование, адрес, телефон и прочую информацию по контрагенту. После ввода сведений
необходимо их сохранить, нажав на кнопку «Сохранить». Введенное значение автоматически отобразится в поле «Заказчик» регистрационной формы
заявки.
Для того чтобы указать, что данная организация фигурирует и как грузоотправитель, и как заказчик, необходимо в регистрационной форме организации (Рисунок 63) установить соответствующие флажки в разделе «Тип организации». В данном разделе можно также указать, является ли контрагент экспедитором, юридическим лицом, грузополучателем, перевозчиком или находится
в черном списке. Удалить запись справочника можно либо из формы управления организациями, нажав на кнопку «Удалить», либо с помощью флажка «Закрыт» в разделе «Тип организации» в карточке конкретной организации. Просмотр удаленных записей осуществляется также как и в справочнике «Водители».
Для поля «Телефон», «Факс» предусмотрена возможность ввода значения
с помощью маски.
При заполнении полей «ИНН» и «КПП» осуществляется проверка ввода
данных Если контрагент является юридическим лицом, то количество символов
в ИНН составляет 10 символов, КПП – 9 символов. Если контрагент представляет собой физическое лицо, то ИНН состоит из 12 символов, поле КПП является недоступным.
В случае если Организация была проверена Службой Безопасности, то
необходимо заполнить поля «Дата проверки» и «Результат проверки». Таким
образом, пользователь может просматривать результат в общем списке организаций.
На карточке конкретной организации существует раздел «Требование», в
котором менеджер может указывать особые условия перевозки грузов от конкретного заказчика. Данные условия будут отображаться на регистрационной
карточке заявки в поле «Дополнительные условия заявки» на вкладке «Сведения» (Рисунок 44).
Поле «Нормативное время» в карточке организации предназначено для
определения средней продолжительности операций. Поле «Предельное отклонение от предпочитаемого времени» предназначено для того, чтобы определить
предельное опоздание выполнения операции, которое приемлемо для той или
иной организацией.
После нажатия на кнопку «Сохранить» будут сохранены все внесенные
изменения, а созданная организация появится в соответствующих выпадающих
списках регистрационной формы заявки (Рисунок 44).
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 62 – Справочник «Организации»
Рисунок 63 – Данные организации
Для каждой организации необходимо указать ее географическое местоположение, которое учитывается при планировании адреса погрузки и/или раз-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
грузки. Если адресов несколько, то они все должны быть указаны в справочнике «Локации» или на вкладке «Локации» на карточке конкретной организации
(Рисунок 64).
Рисунок 64 – Список локаций конкретной организации
3.4.3.6 Справочник «Города»
В справочнике «Города» (Рисунок 65) содержатся сведения о городах с
указанием названия города, региона и страны. Данный справочник предназначен, прежде всего, для ввода сведений о городах, сведений которые отсутствуют в справочнике «Локации». Для того чтобы ввести новую запись, необходимо нажать на кнопку «Создать», расположенную в верхней части формы управления городами и в карточке города (Рисунок 66) ввести следующую информацию (обязательные для заполнения поля помечены пиктограммой ):
­ Название – вводится название города или населенного пункта;
­ Страна – указывается принадлежность к конкретной стране;
­ Регион – указывается область;
­ Район – из выпадающего списка указывается ближайший населенный пункт;
­ Широта и долгота – значения проставляются автоматически после заполнения поля «Привязка» или после указания пункта на карте, расположенной
справа.
Для сохранения введенных значений, необходимо нажать на кнопку «Сохранить».
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 65 – Справочник «Города»
Рисунок 66 – Добавление нового города
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3.4.3.7 Справочник «Локации»
Справочник «Локации» предназначен для:
­ ввода новых адресов;
­ для визуального отображения карты.
Список адресов организован в виде таблицы (Рисунок 67), в которой:
­ по каждому столбцу реализована сортировка (пиктограмма
в заголовке
таблицы);
­ непосредственно под заголовком каждого столбца расположены поля
фильтрации;
­ для ускорения поиска по справочнику реализована строка быстрого поиска.
Поиск осуществляется по любой части слова по любой колонке.
­
Рисунок 67 – Справочник Локаций
Открыть/ Перейти к справочнику лoкаций можно разными способами:
­ с помощью опции меню «Справочники»  «Локации» (Рисунок 67),
­ перейдя на вкладку «Локации» из регистрационной формы конкретной организации/ресурса/корректировки местоположения и т.п.
Для ввода новой локации необходимо нажать на кнопку «Создать» в
справочнике локаций (Рисунок 68). В появившемся окне ввести следующую
информацию (некоторые поля, например, район, населенный пункт не обязательны для заполнения):
­ Название – адрес (начиная с улицы);
­ Страна – выбрать из предлагаемого списка страну;
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Индекс – выбрать из предлагаемого списка индекс;
Регион – выбрать из предлагаемого списка регион;
Район – выбрать из предлагаемого списка район;
Город – выбрать из предлагаемого списка город;
Населенный пункт - выбрать из предлагаемого списка;
Широта и долгота проставляются автоматически в зависимости от указанных выше сведений;
­ Организация – наименование организации выбирается из выпадающего
справочника;
­ Ключевые слова – при необходимости;
­ Вероятность погрузки – проставляется в случае, если у локации резко возрастает вероятность того, что появится новая заявка из данного пункта. Например, Москва - крупный мегаполис, соответственно вероятность того, что
грузовик поедет из Москвы, уже выполняя другую заявку, резко возрастает.
При вводе только города, страна и регион проставляются автоматически.
После ввода данных необходимо сохранить введенные сведения (кнопка
«Сохранить»).
­
­
­
­
­
­
Рисунок 68 – Добавление новой локации
3.4.3.8 Справочники атрибутов
Справочники атрибутов предназначены как для хранения значений
свойств объектов, указанных в основных справочника и формах системы так и
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
для ввода значений, которые в дальнейшем будут отображаться в соответствующих выпадающих списках. К справочникам атрибутов относятся:
­ типы грузов,
­ типы двигателей,
­ типы загрузки,
­ типы прицепов,
­ единицы измерения,
­ значения грузоподъемности,
­ значения объемов,
­ класс опасности,
­ валюта,
­ форма оплаты,
­ единицы длины,
­ единицы веса,
­ виды недоступности ресурсов,
­ дополнительные услуги,
­ классы груза,
­ типы упаковки,
­ группы упаковки,
­ GPS устройства.
Все справочники атрибутов выполнены в табличном виде (Рисунок 69). В
каждом справочнике существует возможность просмотра удаленных записей,
для чего необходимо установить флажок «Показывать удаленные записи». При
необходимости удаленные записи можно восстановить, выделив требуемую запись и нажав на кнопку «Восстановить». Для редактирования значения следует
выделить нужную запись и дважды щелкнуть левой клавишей мыши либо нажать на кнопку «Открыть».
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 69 – Справочники атрибутов МАС УТР
3.4.4 Мониторинг
3.4.4.1 Расписание ресурсов (водители, тягачи, прицепы)
Для представления расписания используемого в системе типа ресурса
(водителя, тягача и прицепа) в МАС УТР используется графическое представление в виде диаграммы Гантта, которая позволяет представить состояние каждого ресурса в интересуемый период времени (Рисунок 70 - Рисунок 72).
По горизонтальной оси на диаграмме откладывается время. Масштаб
шкалы времени можно изменять. При растягивании формы увеличивается количество отображаемых ресурсов
Для ускорения поиска конкретного ресурса используется строка быстрого
поиска: в расписании водителей поиск осуществляется или по имени, или по
отчеству, или по фамилии водителя; в расписании тягачей – по гос. номеру; в
расписании прицепов – по гос. номеру.
При двойном щелчке по состоянию открывается регистрационная форма
заявки (которую выполняет данный ресурс в указанный момент времени), или
экранная форма соответствующего документа.
Реализована возможность скрытия/отображения состояний ресурсов. При
выключении кнопки «Показывать все состояния» на диаграмме Гантта не отображаются состояния «Группировки» и «Свободен», что облегчает читабельность диаграммы Гантта.
Нажатие на кнопку «Расписание по заявкам» позволяет пользователю
увидеть не только запланированные на данный ресурс заявки, но и заявки, в которых данный ресурс фигурирует как предпочитаемый.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Для каждого ресурса на диаграмме Гантта приняты следующие состояния
(для наглядности и удобства пользователя состояния выделены различным цветом):
­ Свободен – зеленый цвет;
­ В пути без груза – цвет фуксии (если переезд осуществляется по заявке);
­ В пути без груза – голубой цвет (если переезд осуществляется не по заявке);
­ Погрузка – серый цвет;
­ В пути загружен – светло-зеленый цвет;
­ Разгрузка – серый цвет;
­ Стоянка с грузом – серый цвет;
­ Недоступен – желтый цвет.
Рисунок 70 – Расписание «Тягачи»
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 71 – Расписание «Водители»
Рисунок 72 – Расписание «Прицепы»
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
3.4.4.2 Расположение тягачей
Опция "Расположение тягачей" предназначена для отображения всех тягачей на указанную дату (Рисунок 73). При наведении курсора мыши на иконку машинки во всплывающем окне отобразится информация о местоположении
данного тягача, его гос. номере и прочее.
Рисунок 73 – Расположение тягачей
3.4.4.3 Просмотр маршрута
«Просмотр маршрута» («Мониторинг»  «Просмотр маршрута»)
(Рисунок 74) предназначен для расчета расстояния между населенными пунктами. На данной экранной форме следует указать пункты «От» и «До». В данных полях указывают адреса, из которых система автоматически производит
расчет расстояния между родительскими узлами (т.е. между населенными
пунктами, а не конкретными адресами).
После ввода начального и конечного пункта система формирует список
промежуточных географических точек с указанием расстояния в километрах, а
также времени перемещения от одной точки до другой.
Если расстояние не может быть рассчитано, на экран выводится предупреждение.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 74 – Просмотр маршрута
3.4.4.4 «Мониторинг заявок»
Пункт меню «Мониторинг заявок» (Рисунок 75) предназначен для отслеживания заявок, имеющих опоздание по той или иной операции. Таким образом, пользователь имеет возможность увидеть, на какой промежуток существует отклонение по времени. Опция представлена в виде таблицы, в которой указывается номер заявки, операция, запланированное время начала операции и
общее время опоздания. По табличным заголовкам также реализована сортировка.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 75 – Окно мониторинга заявок
3.4.4.5 «Мониторинг ресурсов»
Пункт меню «Мониторинг ресурсов» (Рисунок 76) предназначен для отслеживания статуса и местонахождения ресурсов в настоящий момент времени
(водителей, прицепов и тягачей).
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 76 – Окно мониторинга ресурсов
3.4.4.6 «Мониторинг менеджеров»
Пункт меню «Мониторинг менеджеров» позволяет видеть результативность работы менеджеров за указанный период (Рисунок 77). В данном отчете
используются следующие столбцы:
­ филиал – к какому филиалу принадлежит менеджер;
­ менеджер - логин менеджера;
­ заказчик – наименование компании заказчика;
­ всего заявок – сколько заявок было заведено менеджером (с учетом неутвержденных заявок);
­ принято – сколько заявок было принято менеджером (за исключением заявок, имеющих статус «неутвержденная»);
­ не утверждено – сколько введенных заявок осталось неутвержденными ;
­ запланировано – сколько заявок было запланировано менеджером;
­ не под контролем – для данных заявок текущая дата более чем на сутки превышает предпочитаемое время, а фактическое время не было проставлено;
­ выполнено – количество выполненных заявок (имеющих статус «выполнено»);
­ проблемных – количество заявок, которые запланированы с отклонением
предпочитаемого времени от запланированного (опозданием или опережением);
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
­ сумма по заявкам – указывается общая сумма по стоимости от заказчика;
­ суммарное отклонение – указывается суммарное время опоздания (отклонение запланированного времени от предпочитаемого) по всем заявкам за период.
­ максимальное отклонение – указывается максимальное отклонение (опоздание или опережение) из всех имевших место за период.
Для формирования отчета по работе менеджера предусмотрена возможность осуществления группировки по столбцам с подсчетом общего итога. Для
того чтобы получить такое представление отчета, необходимо, удерживая
мышкой, перетащить необходимый столбец в верхнюю часть отчета на место с
надписью «Переместите сюда заголовки колонок для группировки».
Рисунок 77 – Отчет о деятельности менеджеров
3.4.5 Отчеты
Помимо ведения справочной информации в АС УТР предусмотрено ведение отчетной документации. Различают Основные и Вспомогательные отчеты.
К основным отчетам, большинство из которых выводится в виде графиков, относятся:
­ Мониторинг показателей;
­ Уровень сервиса;
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
­ Загруженность ресурсов;
­ Прибытия/отправления;
­ Анализ перевозок.
3.4.5.1 Отчет «Мониторинг показателей»
На графике «Мониторинг показателей» (Рисунок 78) отображаются три
показателя: стоимость от заказчика, стоимость перевозчику и прибыль. Пользователю предоставлена возможность указать конкретного заказчика (поле «Заказчик»), а также филиал. Таким образом, пользователь может увидеть, насколько «выгоден» тот или иной заказчик, а также, сколько прибыли приносит
конкретный филиал компании.
Рисунок 78 – Мониторинг показателей
3.4.5.2 Отчет «Уровень сервиса»
Уровень сервиса (Рисунок 79) позволяет пользователю получить числовое значение качественности выполнения заявки и рассчитывается по следующей формуле:
Предпочитаемое время - Запланированноевремя
Количествозаявок за период
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 79 – Отчет «Уровень сервиса»
3.4.5.3 Отчет «Загруженность ресурсов»
Загруженность ресурсов (Рисунок 80) рассчитывается по следующей
формуле:
Полезноевремя использования ресурса
Общее время использования ресурса
и позволяет определить, какую часть времени заданного периода ресурс был
задействован для выполнения грузоперевозки. Для получения графика загруженности ресурса необходимо указать тип ресурса (водителя или тягач), указать интересующий период и нажать кнопку «Показать».
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 80 – Загруженность водителей
3.4.5.4 Отчет «Прибытия/Отправления»
Отчет «Прибытия/отправления» предназначен для того, чтобы отследить
ресурсы, которые прибывают в конкретный город/его окрестность или отправляются из конкретного города/окрестности за определенный период времени
(Рисунок 81) . Данный отчет позволяет наглядно просмотреть движение ресурсов.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 81 – Отчет «Прибытия/Отправления»
3.4.6 Редактор правил
Редактор правил представляет собой функционал, с помощью которого
пользователь может задавать индивидуальные приоритеты и предпочтения, которые должны учитываться при планировании заявок. Использование редактора правил позволяет учитывать особенности эксплуатации того или иного ресурса, обеспечивая тем самым персонализированный подход в управлении ресурсами.
Редактор правил запускается через меню «Администрирование»  «Редактор правил».
Задание предпочтений осуществляется в три шага:
1. формирование группы заявок;
2. формирование групп ресурсов;
3. редактор общих правил.
Формирование групп заявок
Заявки в АС УТР планируются с «одинаковым» приоритетом. Если возникает необходимость каким-то заявкам дать больший приоритет (например,
заявки от VIP-заказчиков должны быть запланированы в первую очередь), то
пользователь должен выделить данные заявки в отдельную группу.
Для формирования групп заявок следует выбрать пункты меню «Администрирование»  «Редактор правил»  «Формирование групп заявок». В данном окне содержится перечень сформированных групп заявок (Рисунок 82).
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
При выделении в левой части экрана конкретной группы правил в правой части
будут отражены критерии, по которым заявка включается в данную группу.
Чтобы создать новую группу заявок следует нажать кнопку «Добавить
группу» и в появившемся окне следует указать наименование группы, а также
собственно критериев отбора заявок в данную группу.
Правила имеют следующий синтаксис:
<Атрибут> <Оператор сравнения> <Значение>
­ Атрибут – из списка наиболее важных параметров заявки необходимо выбрать требуемый, по нему и будет осуществляться отбор заявок в группу;
­ Оператор сравнения – указывается операция сравнения («содержит», «больше», «меньше», «равно» и т.д.);
­ Значение – пользователь указывает значение атрибута, с которым и осуществляется сравнение.
Условия правила могут быть объединены логическими операторами «И»,
«ИЛИ», «Не И», «Не ИЛИ».
Рисунок 82 – Редактор групп заявок
На Рисунок 83 показан пример создания группы «Самарская заявка».
Сначала необходимо сформулировать само правило: «Под самарской заявкой
понимается заявка, которая была сформирована менеджером самарского филиала и местом отправления (или назначения) которой является город Самара».
В данном правиле содержатся два условия:
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
­ заявка самарского филиала (т.е. в номере заявки должен присутствовать
префикс С);
­ в качестве пункта отправления (назначения) указан город Самара.
Окончательно правило будет иметь вид:
«([Номер заявки] Начинается с С) И (([Город отправления первой погрузки] Содержит Самара) ИЛИ ([Город назначения последней разгрузки] Содержит Самара))».
Рисунок 83 – Редактор правил: окно формирования группы заявок
Формирование групп ресурсов
Формирование групп ресурсов осуществляется аналогично формированию групп заявок (Рисунок 84). Для ресурсов в качестве атрибутов правил указаны наиболее важные параметры ресурсов.
Для формирования группы ресурсов необходимо выбрать пункт меню
«Администрирование»  «Редактор правил»  «Формирование групп ресурсов». В данном окне (Рисунок 85) показаны группы ресурсов.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 84 – Редактор правил: окно формирования группы ресурсов
Рисунок 85 – Редактор правил: окно редактирования группы ресурсов
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Редактор общих правил
Наряду с механизмом сопоставления ресурсов и заявок в системе предусмотрена возможность ввода общих правил. Механизм общих правил позволяет
задавать зависимости не в виде окна сопоставления, а с помощью отдельно заданных правил. Синтаксис общих правил идентичен синтаксису правил групп
заявок и групп ресурсов. Список правил отображается в левой части окна редактора групп (Рисунок 86). Кроме того, в системе предусмотрена возможность указания значений бонусов (как положительных, так и отрицательных).
Назначение бонусов позволяет увеличивать или уменьшать приоритет конкретной группы заявок и ресурсов.
Рисунок 86 – Окно редактора групп
3.4.7 Шаблоны печатных форм
При необходимости пользователь может распечатать готовую форму заявки-договора (Рисунок 87), а также может сформировать шаблон любого требуемого документа для использования его в дальнейшем (Рисунок 88).
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
пиктограмма «Печать»
Рисунок 87 – Форма заявки-договора
Для того чтобы создать собственный шаблон требуемого документа, необходимо в пункте меню «Администрирование»  «Шаблоны печатных форм»
нажать кнопку «Создать» и после кнопку «». Таким образом, отразится печатная форма в режиме конструктора.
В режиме конструктора в левой части экрана отображаются основные
элементы управления; в правой части приведены наименования полей регистрационной формы заявки; в центральной части приводится печатная форма заявки в режиме конструктора.
Пользователь может настраивать форму «под себя», перенося необходимые поля из правой части в печатную форму. Для переноса требуемого поля
необходимо, удерживая левой кнопкой мыши, перетащить поле на нужное место.
После того, как пользователь создал требуемый шаблон документа, его
необходимо сохранить. Для этого необходимо нажать на кнопку «Сохранить
отчет» (Рисунок 87) и переименовать предлагаемое по умолчанию имя файла
(например, XtraReportEdit_Primer.repx). Файлы шаблонов сохраняются с расширением .repx в папку, указанную в пункте меню «Настройки»  «По умолчанию» в поле «Путь к папке печатных форм»
Если в дальнейшем возникнет необходимость распечатать созданный
шаблон печатной формы для любой другой заявки, то необходимо нажать
кнопку «Печать» в окне регистрации данной заявки. При этом в выпадающем
списке отобразятся все созданные шаблоны печатных форм (Рисунок 88).
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
кнопки «Открыть»
и «Сохранить»
печатная форма в
режиме
конструктора
элементы
управления
список полей из
регистрационной
формы заявки
режим «Дизайн»,
«Просмотр», «Просмотр в html»
Рисунок 88 – Редактор печатных форм
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
4 ЦЕЛИ, ЗАДАЧИ И СОДЕРЖАНИЕ ЛАБОРАТОРНОГО
ПРАКТИКУМА
Основные цели лабораторного практикума:
­ Изучение основ мультиагентных технологий и возможных приложений.
­ Изучение мультиагентного подхода к решению задач, связанных с динамическим распределением ресурсов в реальном времени применительно к задачам транспортной логистики.
­ Освоение принципов построения баз знаний (онтологий) открытых мультиагентных систем для транспортной логистики.
­ Изучение инструментария, используемого для создания мультагентных систем планирования ресурсов в реальном времени.
­ Приобретение навыков работы с мультиагентными системами «распределенного интеллекта», агенты которых способны к переговорам и принятию
согласованных решений.
Основные задачи лабораторного практикума:
­ Изучение базовых понятий, определяющих особенности мультиагентного
подхода к управлению транспортными ресурсами.
­ Изучение принципов построения мультиагентных систем, предназначенных
для изучения динамики функционирования сложноорганизованных систем.
­ Освоение онтологического подхода к описанию знаний о структуре и алгоритмах функционирования сложноорганизованных систем.
­ Практическое освоение инструментальных средств мультиагентных приложений, связанных с планированием последовательности событий.
­ Освоение методов проектирования и моделирования онтологической сцены
для сложных задач динамического планирования мрбильных ресурсов в реальном времени.
­ Освоение приемов использования агентов для адаптивного планирования
заявок на перевозку грузов в мультиагентой системе управления транспортными перевозками.
­ Изучение сценариев, реализующих различные алгоритмы планирования заявок на перевозку грузов в мультиагентой системе управления транспортными перевозками.
­ Практическое освоение технологии моделирования процессов взаимодействия между объектами в среде открытой мультиагентной исполняющей системы.
­ Анализ динамики адаптивного планирования и перепланирования расписания перевозок в зависимости от положения мобильных ресурсов на карте и
времени поступления заявок.
В процессе выполнения лабораторного практикума предлагается изучить
возможности применения мультиагентных технологий для решения задач планирования и управления мобльными ресурсами в реальном масштабе времени.
Отметим, что приведенные примеры динамического планирования достаточно широко распространены в различных предметных областях, связанных с
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
линамическим распределением ресурсов. Одной из наиболее перспективных
областей применения данной технологии является управлением перевозками в
транспортно-логистической компании.
Лабораторный практикум посвящен изучению различных аспектов применения мультиагентного подхода при составления расписаний для управлениия транспортными перевозками в транспортно-логистической компании:
1. Последовательное планирование заявок на ресурсы.
2. Планирование заявок на ресурсы с минимальным холостым ходом.
3. Планирование ресурсов с вытеснением заявок.
4. Планирование заявок при недоступности ресурсов.
5. Планирование заявок на предпочитаемые ресурсы.
6. Планирование неприбыльных заявок.
Лабораторные работы выполняются «сквозным» образом так, что результаты текущей работы являются исходными данными для выполнения следующей работы.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
5 ЛАБОРАТОРНЫЙ ПРАКТИКУМ
5.1 Исходная информация для планирования
Карта местности в США, на которой производятся рассматриваемые грузовые перевозки, представлена на Рисунок 89.
Рисунок 89 – География местности
Расстояния между городами задаются матрицей расстояний, представленной в Таблица 5.
Таблица 5 – Матрица расстояний между городами
Route
Mileage, mile
Jacksonville – Henderson
794
Jacksonville – New Albany
1042
Jacksonville – Pageland
586
Pageland – New Albany
949
Pageland – Atlanta
463
New Albany – Atlanta
488
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Перевозки рассматриваются без консолидаций паллет грузов – считается,
что грузовик двигается полным. В данном наборе сценариев не рассматриваются вопросы перегруппировки ресурсов (смены водителей или прицепов) и подбора ресурсов по значениям их свойств.
Для выполнения перевозок в системе имеются три набора ресурсов, идентифицируемых далее по номеру грузовика или по имени водителя. Изначально
все ресурсы находятся в Jacksonville.
­ Joe Best King (Mercedes WRI 3456), location: Jacksonville,
­ Gladys Strong (Freight Liner WRI 2345), location: Jacksonville,
­ Oliver Vogt (Volvo 123456), location: Jacksonville.
На Рисунок 90 представлено начальное состояние ресурсов на карте. На
Рисунок 91 представлено начальное состояние ресурсов в виде расписания.
Рисунок 90 – Начальное состояние ресурсов на карте
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 91 – Начальное состояние ресурсов в расписании
5.2 Рассчитываемые показатели планирования ресурсов
В рассматриваемых ниже сценариях стоимость перевозки заявки (Price)
определяется как установленный компанией тариф по прайс-листу.
Стоимость перевозки заявки = Тариф по прайс-листу
Затраты на перевозку (Expenses) определяются как себестоимость перевозки заявки.
Затраты на перевозку = Себестоимость перевозки
Себестоимость перевозки =
себестоимость перевозки груза на 1 милю * расстояние по маршруту
Expenses = Prime cost * Mileage
Среднюю скорость движения грузовика примем 100 km/hour. Стоимость
использования для всех ресурсов в сценариях одинакова: $30/100km.
В компании предусмотрен штраф за опоздание (Penalty). При расчете
чистой прибыли (Profit) считается, что при отклонении заявки от предпочи-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
таемого времени ее доходность падает на 10% в час.
Чистая прибыль = Стоимость перевозки – Затраты на перевозку – Штраф
Profit = Price – Expenses –Penalty
После поступления очередной заявки оценивается ключево й показатель
эффективности (Key Performance Indicator – KPI), который позволяет оценить
качество различных вариантов планирования. В качестве KPI в системе принята
чистая прибыль.
KPI = Profit
Агенты договариваются между собой и выбирают вариант планирования
с максимальным KPI. При этом действует принцип роста общей ценности
(даже в ущерб интересам отдельных агентов). Когда приходит заявка, она начинает искать себе размещение и планирует цепочку перестановок. Если заявка
неприбыльная и ее планирование не обеспечивает преимущества другим заявкам, то она не планируется. Если цепочка перестановок приводит к росту общих показателей системы (сейчас используется один показатель – прибыль, но
возможно введение новых показателей), то намеченная цепочка принимается и
заявка планируется. Таким образом, даже если сама заявка неприбыльная, но ее
размещение в плане снижает стоимость выполнения других заявок так, что общий KPI системы увеличивается, то заявка планируется.
5.3 Лабораторная работа №1. Создание заявок, построение
начального плана и последовательное планирование заявок
Цель лабораторной работы № 1 – продемонстрировать возможности
мультиагентной автоматизированной системы адаптивного планирования
транспортных ресурсов для реализации распределения заявок по ресурсам при
последовательном поступлении заявок в систему.
В процессе выполнения лабораторной работы № 1 решаются следующие
задачи:
­ Создание заявок;
­ Построение начального плана распределения ресурсов по заявкам;
­ Изучение основных средств представления плана;
­ Освоение приемов автоматического и ручного планирования событий;
­ Изучение алгоритма формирования основных показателей плана и их анализ.
5.3.1 Создание заявок и построение начального плана
Для начала работы с системой необходимо загрузить из внешнего файла
или создать вручную начальные заявки на перевозку, которые далее будут поэтапно отправляться на планирование для моделирования их поступления в ходе реального использования системы. Рассмотрим пять заявок и три ресурса.
Параметры заявок указаны в Таблица 6. Если требуется доезд тягача в пределах
города от точки стоянки к точке погрузки, например, в Jacksonville – доезд до
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
адреса JAX Logistics 123 Happy Street 32203, к расстоянию между городами,
указанному в матрице расстояний, добавляется еще 30 mile. Размещение заявок
на карте представлено на Рисунок 92.
№ заявки
Откуда
AT00001
JAX
8
Logistic
s 123
Happy
Street
32203
AT00002
JAX
2
Logistic
s 123
Happy
Street
32203
AT00002
JAX
3
Logistic
s 123
Happy
Street
32203
AT00003
JAX
2
Logistic
s 123
Happy
Street
32203
AT00003 Pagelan
3
d
Таблица 6 – Параметры заявок
Доезд от месРасСтоита стоянки до стояние мость от
места по, mile
заказгрузки тягачика
ча, mile
794
600
Куда
Погрузка
(предпочитаемое время)
Hender
son
06/13/2009
8:00 AM
New
Albany
06/12/2009
8:00 PM
30
1042
1000
Pageland
06/12/2009
3:00 PM
30
586
600
New
Albany
06/12/2009
9:00 AM
30
1042
900
New
Albany
06/13/2009
4:00 PM
-
949
4000
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Henderson
Pageland
New Albany
AT000033
AT000023
AT000022
AT000032
AT000018
Jacksonville
Рисунок 92 – Размещение заявок на карте
Для ввода новой заявки необходимо в регистрационной форме заявки выбрать опцию меню «Управление»  «Заявки»  «Добавить» (Рисунок 93). Атрибуты для ввода:
­ номер заявки,
­ тип прицепа,
­ грузоподъемность,
­ объем,
­ стоимость от заказчика.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 93 – Экран заявки
В рамках одной заявки может фигурировать несколько операций. Для
операции задаются (Рисунок 94):
­ тип операции,
­ адрес погрузки/разгрузки,
­ длительность операции и/или предпочитаемое время погрузки/разгрузки.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 94 – Экран редактирования операции
На Рисунок 95 представлена форма редактирования заявки AT000032 с
введенными данными.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 95 – Экран заявки AT000032
В систему введено несколько заявок, которые будут поэтапно отправляться на планирование. На Рисунок 96 заявки, участвующие в демонстрационных сценариях, выделены зеленым цветом.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 96 – Список заявок
По нажатию кнопки «Автоматическое планирование» выбранные заявки
отправляются на планирование.
5.3.2 Сценарий последовательного планирования заявок
В данном сценарии выполним последовательное планирование на ресурсы Oliver Vogt, Joe Best King и Gladys Strong заявок AT000032, AT000023,
AT000022.
Пусть на планирование последовательно отправляются заявки AT000032,
AT000023, AT000022. Все три заявки требуют осуществить перевозку груза из
Jacksonville, JAX Logistics 123 Happy Street 32203, и пересекаются по предпочитаемому времени выполнения. Три имеющихся в системе грузовика стоят в
Jacksonville. Характеристики ресурсов идентичны. Характеристики заявок до
планирования приведены в Таблица 7.
Order
AT00003
2
AT00002
3
Departure
JAX Logistics
123 Happy
Street 32203
JAX Logistics
123 Happy
Таблица 7 – Характеристики заявок
Time of Dep.
Arrival
Price, $
06/12/2009 9:00
New AlAM
900
bany
06/12/2009 3:00
PM
Pageland
600
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
AT00002
2
Street 32203
JAX Logistics
123 Happy
Street 32203
06/12/2009 8:00
PM
New Albany
500
После отправки заявок на планирование планировщик распределяет их по
ресурсам. В данном случае все три заявки распределяются на разные ресурсы,
т.к. по всем параметрам ресурсы равнозначны, а заявки должны выполняться с
пересечением по времени. Т.к. все ресурсы идентичны по своим характеристикам, выбор свободного ресурса для первой заявки выполняется случайным образом. Далее при последовательной обработке каждая следующая заявка подбирает себе один из оставшихся свободных ресурсов, который также выбирается случайным образом:
­ AT000032, запланирован на Oliver Vogt,
­ AT000023, запланирован на Joe Best King,
­ AT000022, запланирован на Gladys Strong.
Микроэкономические параметры заявки, а также общей сложившейся ситуации в результате планирования приведены в Таблица 8.
Таблица 8 – Микроэкономические показатели
AT00003 AT00002 AT00002
2
3
2
1072
616
1072
Mileage, mile
900
600
1000
Price, $
321.6
184.8
321.6
Expenses, $
578.4
415.2
678.4
Profit, $
В Таблица 9 и на Рисунок 97 показано, каким образом формируется прибыль заявок при наступлении очередного события, к которым в данном сценарии относятся поступления заявок AT000032, AT000023, AT000022.
The
point
1
2
3
Event
Приход
AT000032
Приход
AT000023
Приход
AT000022
AT0000
32
Таблица 9 – Прибыль в системе
Profit, $
AT0000 AT00002
Total
23
2
578.4
-
-
578.4
578.4
415.2
-
993.6
578.4
415.2
678.4
1672.0
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Прибыль в системе
AT000032
прибыль
AT000023
1800
AT000022
1600
1400
Total
1200
1000
800
600
400
200
события
0
1
2
3
4
5
Рисунок 97 – Прибыль в системе
Событие 1 (точка 1 на графике) соответствует приходу заявки AT000032 в
Jacksonville, JAX Logistics 123 Happy Street 32203. Прибыль в системе от ее
выполнения определяется следующим образом:
Стоимость перевозки заявки – Затраты на перевозку =
900 – 1072*30/100 = 578.4.
Событие 2 (точка 2 на графике) соответствует приходу заявки AT000023 в
Jacksonville, JAX Logistics 123 Happy Street 32203. Прибыль в системе от его
выполнения определяется следующим образом:
Стоимость перевозки заявки – Затраты на перевозку =
600 – 616*30/100 = 415.2.
Событие 3 (точка 3 на графике) соответствует приходу заявки AT000022 в
Jacksonville, JAX Logistics 123 Happy Street 32203. Прибыль в системе от его
выполнения определяется следующим образом:
Стоимость перевозки заявки – Затраты на перевозку =
1000 – 1072*30/100 = 678.4.
Суммарная прибыль в системе складывается из прибыли от заявок
AT000032, AT000023, AT000022, что составляет 1672.0.
Таким образом, на Рисунок 97 показано:
­ прибыль в системе при перевозке заявки AT000032 из Jacksonville, JAX
Logistics 123 Happy Street 32203 в New Albany, при перевозке заявки
AT000023 из Jacksonville, JAX Logistics 123 Happy Street 32203 в Pageland,
при перевозке заявки AT000022 из Jacksonville, JAX Logistics 123 Happy
Street 32203 в New Albany.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
На Рисунок 98 показано состояние списка заявок после планирования
(статус заявок AT000032, AT000023, AT000022 сменился на Planned, указана
дата разгрузки и характеристики водителя).
Рисунок 98 – Состояние списка заявок после планирования
На Рисунок 99 и в Таблица 10 показано расписание ресурсов после планирования. На Рисунок 100 представлена форма заявки AT000032 после его
планирования (указаны транспортные расходы и прибыль от выполнения заявки).
Resource
Joe Best
King
Gladys
Strong
Oliver
Vogt
Таблица 10 – Расписание ресурсов после планирования
Departure
Time of Dep.
Arrival
Time of Arr.
06/12/2009 3:00
06/12/2009 9:25
Jacksonville
Pageland
PM
PM
06/12/2009 8:00 New Al- 06/13/2009 7:10
Jacksonville
PM
bany
AM
06/12/2009 9:00 New Al- 06/12/2009 7:40
Jacksonville
AM
bany
PM
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
­
Рисунок 99 – Расписание ресурсов после планирования
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 100 – Форма заявки AT000032 после планирования
5.3.3 Индивидуальные задания
1. Создайте две заявки и три ресурса. Последовательно запланируйте заявки. Наблюдайте, как изменится расписание ресурсов, опишите полученные
результаты. Проанализируйте основные показатели плана.
5.4 Лабораторная работа №2. Подбор ресурса с минимальным
холостым ходом
Цель лабораторной работы № 2 – продемонстрировать возможности
мультиагентной автоматизированной системы адаптивного планирования
транспортных ресурсов для реализации распределения заявок по ресурсам таким образом, чтобы подобрать ресурсы с минимальными порожними перегонами.
В процессе выполнения лабораторной работы № 2 решаются следующие
задачи:
­ создание заявки;
­ построение начального плана распределения ресурсов по заявкам;
­ изучение основных средств представления плана;
­ освоение приемов автоматического и ручного планирования событий;
­ изучение алгоритма формирования основных показателей плана, на основании которых агенты в процессе переговоров принимают решение о планировании заявок на ресурсы с минимальными порожними перегонами;
­ анализ основных показателей плана.
5.4.1 Сценарий планирования заявок на ресурсы с минимальным
холостым ходом
Покажем планирование заявки AT000018 с последующим размещением
заявки AT000018 на ресурс Joe Best King.
Запланируем заявку AT000018 с характеристиками, указанными в Таблица 11. Планируемое расположение ресурсов на момент предпочитаемого начала выполнения заявки AT000018 приведено на Рисунок 101 (стрелками показаны возможные пустые перегоны ресурсов).
Order
AT00001
8
Таблица 11 – Характеристики заявки AT000018
Departure
Time of Dep.
Arrival
Price, $
JAX Logistics
06/13/2009 8:00
Hender123 Happy
600
AM
son
Street 32203
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Henderson
Pageland
New Albany
King
AT000033
Vogt
Strong
AT000018
Jacksonville
Рисунок 101 – Расположение ресурсов на момент начала выполнения заявки AT000018
Т.к. заявка AT000018 загружается в Jacksonville, требуется пустой перегон. Агент заявки рассматривает три варианта планирования на разные ресурсы. В Таблица 12 показано планируемое прибытие ресурсов к точке выполнения заявки AT000018 с учетом времени разгрузки в Pageland и New Albany и
времени в пути до Jacksonville.
Таблица 12 – Планируемое прибытие ресурсов к точке выполнения заявки
AT000018
DeparВремя
Time of
ВреВремя
Reture
окончания
Dep.
мя в Time of
разArrival
sorce
предыдупути
Arr.
грузки
щей заявки
Pageland 06/12/2009
0:55
06/12/2009
Jackson5:45 06/13/20
Joe
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
9:25 PM
Best
King
Gladys
Strong
Oliver
Vogt
New Albany
06/13/2009
7:10 AM
New Albany
06/12/2009
7:40 PM
10:20 PM
ville
0:45
06/13/2009
7:55 AM
Jacksonville
0:45
06/12/2009
8:25 PM
Jacksonville
10:10
10:10
09 4:05
AM
06/13/20
09 6:05
PM
06/13/20
09 6:35
AM
Из Таблица 12 следует, что планирование на Gladys Strong приводит к
опозданию на 10 час 05 мин. Поэтому агент заявки будет оценивать варианты
планирования на Oliver Vogt (Таблица 13) и Joe Best King (Таблица 14).
В Таблица 13 и на Рисунок 102 показано, каким образом формируется
прибыль в системе от планирования заявки AT000018 на Oliver Vogt при наступлении очередного события, к которым в данном примере относятся приход заявки AT000018, порожний перегон New Albany – Jacksonville и перевозка
Jacksonville – Henderson.
Таблица 13 – Микроэкономические показатели планирования заявки
AT000018 на Oliver Vogt
Lag
Total
Jax - HenderNew Albany son
Jax
1042
794
1836
Mileage, mile
600
Price, $
312.6
238.2
550.8
Expenses, $
49.2
Profit, $
Прибыль в системе от планирования заявки AT000018
на Oliver Vogt
800
Lag
Jax-Hend
600
прибыль
AT000018
Total
400
200
0
-200
-400
0
1
2
3
4 события
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 102 – Прибыль в системе от планирования заявки AT000018 на
Oliver Vogt
Событие 1 (точка 1 на графике) соответствует приходу заявки AT000018 в
Jacksonville. Прибыль в системе от ее выполнения определяется следующим
образом:
Стоимость перевозки заявки = 600.
Событие 2 (точка 2 на графике) соответствует порожнему перегону New
Albany – Jacksonville. Прибыль в системе от его выполнения определяется следующим образом:
Стоимость перевозки заявки – Затраты на порожний перегон =
600 – 1042*30/100 = 287.4.
Событие 3 (точка 3 на графике) соответствует перевозке заявки AT000018
из Jacksonville в Henderson. Прибыль в системе от его выполнения определяется следующим образом:
Стоимость перевозки заявки – Затраты на порожний перегон – Затраты на
перевозку = 600 – 1042*30/100 – 794*30/100 = 49.2.
Прибыль в системе от планирования заявки AT000018 на Oliver Vogt составляет 49.2.
Таким образом, на Рисунок 102 показано:
­ прибыль в системе от планирования заявки AT000018 на Oliver Vogt, включающего приход заявки AT000018, порожний перегон New Albany –
Jacksonville и перевозку Jacksonville – Henderson.
­
В Таблица 14 и на Рисунок 103 показано, каким образом формируется
прибыль в системе от планирования заявки AT000018 на Joe Best King при наступлении очередного события, к которым в данном примере относятся приход
заявки AT000018, порожний перегон Pageland – Jacksonville и перевозка
Jacksonville – Henderson.
Таблица 14 - Микроэкономические показатели планирования заявки
AT000018 на Joe Best King
Lag
Jax - HenderTotal
Pageland - Jax
son
586
794
1380
Mileage, mile
600
Price, $
175.8
238.2
414
Expenses, $
186
Profit, $
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Прибыль в системе от планирования заявки AT000018
на Joe Best King
AT000018
Lag
800
Jax-Hend
прибыль
600
Total
400
200
0
-200
0
1
2
3
4
события
-400
Рисунок 103 – Прибыль в системе от планирования заявки AT000018 на
Joe Best King
Событие 1 (точка 1 на графике) соответствует приходу заявки AT000018 в
Jacksonville. Прибыль в системе от ее выполнения определяется следующим
образом:
Стоимость перевозки заявки = 600.
Событие 2 (точка 2 на графике) соответствует порожнему перегону Pageland – Jacksonville. Прибыль в системе от его выполнения определяется следующим образом:
Стоимость перевозки заявки – Затраты на порожний перегон =
600 – 586*30/100 = 424.2.
Событие 3 (точка 3 на графике) соответствует перевозке заявки
AT000018 из Jacksonville в Henderson. Прибыль в системе от его выполнения
определяется следующим образом:
Стоимость перевозки заявки – Затраты на порожний перегон – Затраты на
перевозку = 600 – 586*30/100 – 794*30/100 = 186.
Прибыль в системе от планирования заявки AT000018 на Joe Best King
составляет 186.
Таким образом, на Рисунок 103 показано:
­ прибыль в системе от планирования заявки AT000018 на Joe Best King,
включающего приход заявки AT000018, порожний перегон Pageland –
Jacksonville и перевозку Jacksonville – Henderson.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Прибыль в системе от планирования заявки AT000018 на Joe Best King
выше, чем на Oliver Vogt, следовательно, заявка AT000018 будет запланирована на Joe Best King. На Рисунок 104 представлено расписание после планирования заявки AT000018.
Рисунок 104 – Расписание после планирования заявки AT000018
5.4.2 Индивидуальные задания
1. Создайте две заявки и четыре ресурса так, чтобы для загрузки заявок на
некоторые из ресурсов потребовался холостой перегон. Последовательно запланируйте заявки так, чтобы выбрать ресурсы с минимальным холостым перегоном. Наблюдайте, как изменится расписание ресурсов, опишите полученные
результаты. Проанализируйте основные показатели плана.
5.5 Лабораторная работа №3. Перепланирование заявок по ресурсам
в случае появления более выгодной заявки
Цель лабораторной работы № 3 – продемонстрировать, каким образом в
мультиагентной автоматизированной системе адаптивного планирования
транспортных ресурсов выполняется перепланирование заявок по ресурсам путем вытеснения ранее запланированных заявок и перехода их на другие ресурсы при появлении в системе более выгодной заявки.
В процессе выполнения лабораторной работы № 3 решаются следующие
задачи:
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
создание заявки;
изучение основных средств представления плана;
изучение логики перепланирования ресурсов;
изучение алгоритма формирования основных показателей плана, на основании которых агенты в процессе переговоров принимают решение о перепланировании заявок на ресурсы;
­ анализ основных показателей плана.
­
­
­
­
5.5.1 Сценарий перепланирования ресурсов с вытеснением заявок
Покажем вытеснение с ресурса Joe Best King ранее запланированной на
него заявки AT000018 при размещении заявки AT000033, перепланирование
расписания вследствие размещения заявки AT000033 на ресурс Joe Best King и
перемещения вытесненной заявки AT000018 на ресурс Oliver Vogt.
Запланируем заявку AT000033 с характеристиками, указанными в Таблица 15.
Order
AT00003
3
Таблица 15 – Характеристики заявки AT000033
Departure
Time of Dep.
Arrival
Price, $
06/13/2009 4:00 New AlPageland
4000
PM
bany
Заявка AT000033 по времени должна начаться позже заявки AT000018.
Заявка AT000033 загружается в Pageland, где с 06/12/2009 9:25 PM стоит грузовик с водителем Joe Best King (Рисунок 101). При таком варианте планирования
прибыльность заявки потенциально составит 4000-949*30/100=3715.3 (Таблица
16, Рисунок 105), но возникает конфликт с заявкой AT000018.
Таблица 16 - Микроэкономические показатели планирования заявки
AT000033 на Joe Best King
Pageland – New
Albany
949
Mileage, mile
4000
Price, $
284.7
Expenses, $
3715.3
Profit, $
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Прибыль в системе от планирования заявки AT000033 на
Joe Best King
AT000018
5000
Pag - New Albany
Total
прибыль
4000
3000
2000
1000
0
-1000
0
1
2
3
события
Рисунок 105 – Прибыль в системе от планирования заявки AT000033 на
Joe Best King
Событие 1 (точка 1 на графике) соответствует приходу заявки AT000033 в
Pageland. Прибыль в системе от ее выполнения определяется следующим образом:
Стоимость перевозки заявки = 4000.
Событие 2 (точка 2 на графике) соответствует перевозке заявки AT000033
из Pageland в New Albany. Прибыль в системе от его выполнения определяется
следующим образом:
Стоимость перевозки заявки – Затраты на перевозку =
4000 –949*30/100 = 3715.3.
Таким образом, на Рисунок 106 показано:
­ прибыль в системе от планирования заявки AT000033 на Joe Best King,
включающего приход заявки AT000033 и перевозку Pageland - New Albany.
Заявка AT000018 может быть запланирована на Oliver Vogt (Таблица 13,
Рисунок 102). Прибыль от планирования заявки AT000018 на Oliver Vogt составит 600-1836*30/100=49.2.
Если планировать заявку AT000033 на другой ресурс (Oliver Vogt), потребуется пустой перегон New Albany – Pageland, и грузовик прибудет в пункт
погрузки с опозданием на 1:54 (Таблица 17).
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Таблица 17 – Планируемое прибытие ресурса к точке выполнения заявки
AT000033
DeparВремя
Time of
ВреВремя
Reture
окончания
Dep.
мя в Time of
разгрузArrival
sorce
предыдупути
Arr.
ки
щей заявки
New Al- 06/12/2009
9:29 06/13/20
06/12/2009
Oliver
bany
7:40 PM
0:45
Pageland
09 5:54
8:25 PM
Vogt
AM
Агент заявки оценивает вариант планирования заявки AT000033 на
Oliver Vogt (Таблица 18).
В Таблица 18 и на Рисунок 106 показано, каким образом формируется
прибыль в системе от планирования заявки AT000033 на Oliver Vogt при наступлении очередного события, к которым в данном примере относятся приход заявки AT000033, порожний перегон New Albany – Pageland, опоздание в пункт
погрузки в Pageland и перевозка Pageland - New Albany.
Таблица 18 – Микроэкономические показатели планирования заявки
AT000033 на Oliver Vogt
Lag
Delay
Total
Pageland New Albany - PaNew Albany
geland
949
949
1898
Mileage, mile
4000
Price, $
284.7
760
284.7
1329.4
Expenses, $
2670.6
Profit, $
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Прибыль в системе от планирования заявки AT000033 на
Oliver Vogt
AT000018
Lag
5000
Delay
прибыль
4000
Pag - New Albany
Total
3000
2000
1000
0
-1000
0
1
2
3
4
5
события
Рисунок 106 – Прибыль в системе от планирования заявки AT000033 на
Oliver Vogt
Событие 1 (точка 1 на графике) соответствует приходу заявки AT000033 в
Pageland. Прибыль в системе от ее выполнения определяется следующим образом:
Стоимость перевозки заявки = 4000.
Событие 2 (точка 2 на графике) соответствует порожнему перегону New
Albany – Pageland. Прибыль в системе от его выполнения определяется следующим образом:
Стоимость перевозки заявки – Затраты на порожний перегон =
4000 – 949*30/100 = 3715.3.
Событие 3 (точка 3 на графике) соответствует опозданию заявки
AT000033 в пункт погрузки в Pageland. Прибыль в системе от его выполнения
определяется следующим образом:
Стоимость перевозки заявки – Затраты на порожний перегон – Штраф за
опоздание = 4000 – 949*30/100 – 4000*19/100 = 2955.3.
Т.к. при опоздании прибыльность заявки снижается на 10% в час, то за
1:54 опоздания прибыльность заявки снизится на 19%.
Событие 4 (точка 4 на графике) соответствует перевозке заявки AT000033
из Pageland в New Albany. Прибыль в системе от его выполнения определяется
следующим образом:
Стоимость перевозки заявки – Затраты на порожний перегон – Штраф за
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
опоздание – Затраты на перевозку = 4000 – 949*30/100 – 4000*19/100 –
949*30/100 = 2670.6.
Таким образом, на Рисунок 106 показано:
­ прибыль в системе от планирования заявки AT000033 на Oliver Vogt, включающего приход заявки AT000033, порожний перегон New Albany –
Pageland, опоздание в Pageland и перевозку Pageland - New Albany.
Прибыль в системе от планирования заявки AT000033 на Oliver Vogt составляет 2670.6, что хуже варианта планирования на Joe Best King (прибыль
3715.3). Поэтому заявка AT000033 планируется на ресурс Joe Best King, вытесняя заявку AT000018, которая уходит на Oliver Vogt. Расписание и состояние заявок после перепланирования представлено на Рисунок 107 и Рисунок 108.
Рисунок 107 – Расписание после вытеснения заявки AT000018
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 108 – Состояние списка заявок после вытеснения заявки
AT000018
5.5.2 Индивидуальные задания
1. Создайте две заявки и три ресурса. Последовательно запланируйте заявки. Создайте заявку с более высокой стоимостью. Наблюдайте, как изменится
расписание ресурсов, опишите полученные результаты. Проанализируйте основные показатели плана.
5.6 Лабораторная работа №4. Планирование заявок по ресурсам в
случае недоступности ресурса
Цель лабораторной работы № 4 – продемонстрировать, каким образом в
мультиагентной автоматизированной системе адаптивного планирования
транспортных ресурсов выполняется перепланирование заявок по ресурсам в
случае недоступности некоторого ресурса.
В процессе выполнения лабораторной работы № 4 решаются следующие
задачи:
­ создание заявки;
­ изучение средств задания недоступности ресурса;
­ изучение логики перепланирования ресурсов;
­ изучение алгоритма формирования основных показателей плана, на основании которых агенты в процессе переговоров принимают решение о перепланировании заявок на ресурсы;
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
­ анализ основных показателей плана.
­
5.6.1 Сценарий перепланирования ресурсов при недоступности ресурса
Покажем планирование в условиях недоступности ресурса Joe Best King,
что приведет к вытеснению с него прибыльной заявки AT000033, которая
перепланируется на ресурс Oliver Vogt, вытесняя с него менее прибыльную
заявку AT000018, которая из-за штрафов на возникающие опоздания окажется незапланированной.
Заявки AT000032, AT000023, AT000022 помечаются на начало выполнения, чтобы планировщик не изменял их расписание.
Вводится недоступность ресурса Joe Best King на весь день 13/06/2009 с
помощью последовательного выполнения команд «Управление»  «Период
недоступности»  «Добавить» и заполнения экранной формы для соответствующего водителя (Рисунок 109).
Рисунок 109 – Задание недоступности ресурса Joe Best King
Расположение ресурсов на момент начала планирования заявок AT000018
и AT000033 показано на Рисунок 110.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Henderson
Pageland
New Albany
AT000033
Vogt
Strong
AT000018
Jacksonville
Рисунок 110 – Расположение ресурсов при недоступности ресурса Joe Best
King
Недоступность ресурса Joe Best King приводит к вытеснению прибыльной заявки AT000033. После вытеснения заявки AT000033 она может быть
запланирована на Oliver Vogt, но при этом вытесняется заявка AT000018, которая потом не может быть никуда запланирована из-за штрафов на возникающие опоздания. Т.к. заявка AT000033 существенно дороже заявки
AT000018, вариант перепланирования с вытеснением принимается, и расписание перестраивается (Рисунок 111).
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 111 – Расписание после перепланирования вследствие недоступности ресурса Joe Best King
В Таблица 18 и на Рисунок 106 показано, каким образом формируется
прибыль в системе от планирования заявки AT000033 на Oliver Vogt при наступлении очередного события, к которым в данном примере относятся приход заявки AT000033, порожний перегон New Albany – Pageland, опоздание
в пункт погрузки в Pageland и перевозка Pageland - New Albany.
На экране состояния заявок (Рисунок 112) видно, что заявка AT000033
запланирована с проблемами (опоздание, статус Issue), а заявка AT000018 не
запланирована вообще (статус Is in planning).
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 112 – Экран состояния заявок (AT000018 не запланирована,
AT000033 запланирована с опозданием)
5.6.2 Индивидуальные задания
1. Создайте две заявки и три ресурса. Запланируйте недоступность одного
из ресурсов. Последовательно запланируйте заявки. Наблюдайте, как изменится
расписание ресурсов, опишите полученные результаты. Проанализируйте основные показатели плана.
5.7 Лабораторная работа №5. Планирование заявок на
предпочитаемые ресурсы
Цель лабораторной работы № 5 – продемонстрировать, каким образом в
мультиагентной автоматизированной системе адаптивного планирования
транспортных ресурсов выполняется перепланирование заявок по ресурсам в
случае планирования на ресурс, которому отдается предпочтение по некоторым
критериям.
В процессе выполнения лабораторной работы № 5 решаются следующие
задачи:
­ изучение средств задания предпочитаемого ресурса;
­ изучение логики перепланирования ресурсов;
­ изучение алгоритма формирования основных показателей плана, на основании которых агенты в процессе переговоров принимают решение о перепланировании заявок на ресурсы;
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
­ анализ основных показателей плана.
­
5.7.1 Сценарий планирования заявок на предпочитаемые ресурсы
Покажем планирование заявки AT000033 на предпочитаемый ресурс
Gladys Strong, вследствие чего заявка AT000033 уйдет с ресурса Oliver Vogt,
на который переместится заявка AT000018.
В заявке AT000033, которая в данный момент запланирована на Oliver
Vogt, указывается предпочитаемый ресурс (Gladys Strong), как показано на
Рисунок 113. Изначально предпочитаемое время погрузки заявки AT000033
06/13/2009 4:00 PM. При планировании на предпочитаемый ресурс перенесем предпочитаемое время погрузки заявки AT000033 на 06/13/2009 2:00
PM.
Рисунок 113 – Задание предпочитаемого ресурса
Расположение ресурсов на момент начала планирования заявок AT000018
и AT000033 показано на Рисунок 110. Если планировать заявку AT000033 на
Gladys Strong, потребуется пустой перегон New Albany – Pageland, и грузовик прибудет в пункт погрузки с опозданием на 3:24 (Таблица 19).
Таблица 19 – Планируемое прибытие ресурса к точке выполнения заявки
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Resorce
Gladys
Strong
Departure
New Albany
Время
окончания
предыдущей заявки
06/13/2009
7:10 AM
AT000033
Time of
Время
Dep.
разгрузки
0:45
06/13/2009
7:55 AM
Arrival
Pageland
Время
в пути
9:29
Time of
Arr.
06/13/20
09 5:24
PM
Агент заявки оценивает вариант планирования заявки AT000033 на
Gladys Strong. В Таблица 20 и на Рисунок 114 показано, каким образом формируется прибыль в системе от планирования заявки AT000033 на Gladys Strong
при наступлении очередного события, к которым в данном примере относятся
приход заявки AT000033, порожний перегон New Albany – Pageland, опоздание
в пункт погрузки в Pageland и перевозка Pageland - New Albany.
Таблица 20 – Микроэкономические показатели планирования заявки
AT000033 на Gladys Strong
Lag
Delay
Total
Pageland New Albany - PaNew Albany
geland
949
949
1898
Mileage, mile
4000
Price, $
284.7
1360
284.7
1929.4
Expenses, $
2070.6
Profit, $
Рисунок 114 – Прибыль в системе от планирования заявки AT000033 на
Gladys Strong
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Событие 1 (точка 1 на графике) соответствует приходу заявки AT000033 в
Pageland. Прибыль в системе от ее выполнения определяется следующим образом:
Стоимость перевозки заявки = 4000.
Событие 2 (точка 2 на графике) соответствует порожнему перегону New
Albany – Pageland. Прибыль в системе от его выполнения определяется следующим образом:
Стоимость перевозки заявки – Затраты на порожний перегон =
4000 – 949*30/100 = 3715.3.
Событие 3 (точка 3 на графике) соответствует опозданию заявки
AT000033 в пункт погрузки в Pageland. Прибыль в системе от его выполнения
определяется следующим образом:
Стоимость перевозки заявки – Затраты на порожний перегон – Штраф за
опоздание = 4000 – 949*30/100 – 4000*34/100 = 2355.3.
Т.к. при опоздании прибыльность заявки снижается на 10% в час, то за
3:24 опоздания прибыльность заявки снизится на 34%.
Событие 4 (точка 4 на графике) соответствует перевозке заявки AT000033
из Pageland в New Albany. Прибыль в системе от его выполнения определяется
следующим образом:
Стоимость перевозки заявки – Затраты на порожний перегон – Штраф за
опоздание – Затраты на перевозку = 4000 – 949*30/100 – 4000*34/100 –
949*30/100 = 2070.6.
Таким образом, на Рисунок 114 показано:
­ прибыль в системе от планирования заявки AT000033 на Gladys Strong,
включающего приход заявки AT000033, порожний перегон New Albany –
Pageland, опоздание в Pageland и перевозку Pageland - New Albany.
Запланировать заявку AT000033 на Gladys Strong можно только с опозданием, поэтому заявка становится менее прибыльной. После планирования заявки AT000033 на предпочитаемый ресурс, заявка AT000033 уходит с Oliver Vogt,
на котором она ранее был запланирована. В результате, заявка AT000018, которая до этого находилась в незапланированном состоянии, планируется на освободившееся место на ресурсе Oliver Vogt без опоздания.
В Таблица 13 и на Рисунок 102 показано, каким образом формируется
прибыль в системе от планирования заявки AT000018 на Oliver Vogt при наступлении очередного события, к которым в данном примере относятся приход за-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
явки AT000018, порожний перегон New Albany – Jacksonville и перевозка
Jacksonville – Henderson. Прибыль от выполнения заявки составляет 49.2. Полученное расписание представлено на Рисунок 115.
Рисунок 115 – Расписание после перепланирования заявки AT000033 на
предпочитаемый ресурс Gladys Strong
Экран состояния заявок представлен на Рисунок 116. На экране состояния
заявок видно, что заявка AT000033 запланирована с проблемами (опоздание,
статус Issue), а заявка AT000018 запланирована (статус Planned).
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 116 – Экран состояния заявок после планирования заявки
AT000033 на предпочитаемый ресурс Gladys Strong
5.7.2 Индивидуальные задания
1. Создайте две заявки и три ресурса. Задайте один из ресурсов как предпочитаемый. Последовательно запланируйте заявки. Наблюдайте, как изменится расписание ресурсов, опишите полученные результаты. Проанализируйте
основные показатели плана.
5.8 Лабораторная работа №6. Планирование неприбыльной заявки
Цель лабораторной работы № 6 – продемонстрировать, каким образом в
мультиагентной автоматизированной системе адаптивного планирования
транспортных ресурсов может быть запланирована неприбыльная заявка, если
ее размещение позволит снизить стоимость выполнения других заявок так, что
общий KPI системы при этом увеличится.
В процессе выполнения лабораторной работы № 6 решаются следующие
задачи:
­ изучение средств задания предпочитаемого ресурса;
­ изучение логики перепланирования ресурсов;
­ изучение алгоритма формирования основных показателей плана, на основании которых агенты в процессе переговоров принимают решение о планировании неприбыльной заявки;
­ анализ основных показателей плана.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Покажем, каким образом в системе может быть запланирована неприбыльная заявка, если в результате размещения ее в плане снижается стоимость
выполнения других заявок так, что общий KPI системы увеличивается. Рассмотрим сценарий планирования для одного ресурса и двух заявок, одна из которых является неприбыльной.
Пусть в системе имеются 2 заявки, параметры которых указаны в Таблица 21. Размещение заявок на карте представлено на Рисунок 117.
№ за- Откуявки
да
AT000
033
AT000
036
Таблица 21 – Параметры заявок
Погрузка
Доезд
от Расстоя(предпочиместа сто- ние, mile
таемое время) янки
до
места
погрузки тягача, mile
06/13/2009 4:00
949
PM
06/13/2009 4:00
488
AM
Куда
Pagela New
nd
Albany
New
Atlanta
Albany
Henderson
Pageland
New Albany
Gladys
AT000033
Strong
AT000033
AT000023
AT000036
AT000022
AT000032
Atlanta
AT000018
Jacksonville
Рисунок 117 – Размещение заявок на карте
Стоимость от
заказчика
4000
100
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Состояние ресурсов определяется следующим образом:
­ Gladys Strong стоит в New Albany,
­ Oliver Vogt стоит в Jacksonville,
­ Joe Best King недоступен.
Gladys Strong является предпочитаемым ресурсом для планирования заявок AT000033 и AT000036.
5.8.1 Сценарий раздельного планирования неприбыльной и прибыльной
заявок
По времени заявка AT000036 должна начаться раньше, чем заявка
AT000033. Попытаемся запланировать заявку AT000036 с характеристиками,
указанными в Таблица 21, на предпочитаемый ресурс Gladys Strong. Экран заявки AT000036 показан на Рисунок 118.
Рисунок 118 – Экран заявки AT000036
Заявка AT000036 загружается в New Albany, где стоит грузовик с водителем Gladys Strong.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Прибыль в системе от выполнения заявки AT000036 определяется следующим образом:
Стоимость перевозки заявки – Затраты на перевозку =
100 – 488*30/100 = -46.4.
Микроэкономические показатели планирования заявки AT000036 на
Gladys Strong приведены в Таблица 22. Планирование заявки AT000036 фактически является убыточным.
Таблица 22 - Микроэкономические показатели планирования заявки
AT000036 на Gladys Strong
New Albany – Atlanta
488
Mileage, mile
100
Price, $
146.4
Expenses, $
-46.4
Profit, $
Заявка AT000036 не будет запланирована, т.к. ее планирование снижает
общий KPI системы. Экран состояния заявок представлен на Рисунок 119. На
экране состояния заявок видно, что заявка AT000036 не запланирована (статус
Is in Planning).
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 119 – Экран состояния заявок после планирования заявки
AT000036 на предпочитаемый ресурс Gladys Strong
Расписание после планирования заявки AT000036 представлено на Рисунок 120. Заявка AT000036 не запланирована, т.к. в расписании Gladys Strong
нет ни одного стейта.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 120 – Расписание после планирования заявки AT000036 на предпочитаемый ресурс Gladys Strong
Запланируем заявку AT000033 на предпочитаемый ресурс Gladys Strong.
Экран заявки AT000033 представлен на Рисунок 121.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 121 – Экран заявки AT000033
Т.к. заявка AT000033 загружается в Pageland, а водитель Gladys Strong
стоит в New Albany, требуется порожний перегон New Albany – Pageland. Прибыль в системе от выполнения заявки AT000033 определяется следующим образом:
Стоимость перевозки заявки – Затраты на порожний перегон – Затраты на
перевозку = 4000 – 949*30/100 – 949*30/100 = 3430.6.
Микроэкономические показатели планирования заявки AT000033 на
Gladys Strong приведены в Таблица 23.
Таблица 23 - Микроэкономические показатели планирования заявки
AT000033 на Gladys Strong
New Albany – Atlanta
949
Mileage, mile
4000
Price, $
569.4
Expenses, $
3430.6
Profit, $
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Заявка AT000033 будет запланирована на Gladys Strong.
5.8.2 Сценарий совместного планирования неприбыльной и
прибыльной заявок
Т.к. Atlanta находится на пути пустого перегона New Albany – Pageland,
можно попытаться запланировать заявки AT000033 и AT000036 таким образом,
чтобы водитель Gladys Strong сначала выполнил заявку AT000036, а затем –
AT000033.
Запланируем заявку AT000036 на предпочитаемый ресурс Gladys Strong.
Микроэкономические показатели планирования заявки AT000036 на Gladys
Strong приведены в Таблица 22.
Далее запланируем заявку AT000033 на предпочитаемый ресурс Gladys
Strong. Т.к. заявка AT000033 загружается в Pageland, требуется порожний перегон Atlanta – Pageland.
Микроэкономические показатели планирования заявок AT000036 и
AT000033 приведены в Таблица 24.
Таблица 24 – Микроэкономические показатели планирования заявки
AT000036 на Gladys Strong
AT000036
AT000033
Lag
Total
Pageland –
New Albany Atlatna - PaNew Albany
- Atlanta
geland
488
463
949
1900
Mileage, mile
100
4000
4100
Price, $
146.4
138.9
284.7
570
Expenses, $
-46.4
-138.9
3715.3
3530
Profit, $
В Таблица 25 и на Рисунок 122 показано, каким образом формируется
прибыль в системе от планирования заявок AT000036 и AT000033 на Gladys
Strong при наступлении очередного события, к которым в данном примере относятся приход заявки AT000036, перевозка New Albany – Atlanta, приход заявки AT000033, порожний перегон Atlanta – New Albany и перевозка Pageland –
New Albany.
Таблица 25 – Прибыль в системе
Profit, $
The
Event
AT0000 AT0000
point
Total
36
33
Приход
100
100
1
AT000036
Перевозка
-46.4
-46.4
2
New Albany Atlanta
Приход
-46.4
4000
3953.6
3
AT000033
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Lag Atlanta Pageland
Перевозка Pageland – New
Albany
4
5
-46.4
3861.1
3814.7
-46.4
3576.4
3530
Прибыль от планирования заявок AT000036 и AT000033 на
Gladys Strong
AT000036
AT000033
4500
Total
4000
3500
прибыль
3000
2500
2000
1500
1000
500
события
0
-500
0
1
2
3
4
5
6
Рисунок 122 – Прибыль в системе
Событие 1 (точка 1 на графике) соответствует приходу заявки AT000036 в
New Albany. Прибыль в системе от ее выполнения определяется следующим
образом:
Стоимость перевозки заявки = 100.
Событие 2 (точка 2 на графике) соответствует перевозке New Albany – Atlanta. Прибыль в системе от ее выполнения определяется следующим образом:
Стоимость перевозки заявки – Затраты на перевозку =
100 – 488*30/100 = -46.4.
Событие 3 (точка 3 на графике) соответствует приходу заявки AT000033 в
Pageland. Прибыль в системе от ее выполнения определяется следующим образом:
Стоимость перевозки заявки = 4000.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Событие 4 (точка 4 на графике) соответствует порожнему перегону Atlanta – Pageland. Прибыль в системе от его выполнения определяется следующим
образом:
Стоимость перевозки заявки – Затраты на порожний перегон =
4000 – 463*30/100 = 3861.1.
Событие 5 (точка 5 на графике) соответствует перевозке заявки AT000033
из Pageland в New Albany. Прибыль в системе от ее выполнения определяется
следующим образом:
Стоимость перевозки заявки – Затраты на порожний перегон – Затраты на
перевозку = 4000 – 463*30/100 – 949*30/100 = 3576.4.
Суммарная прибыль от планирования двух заявок AT000036 и AT000033
на предпочитаемый ресурс Gladys Strong составляет -46.4 + 3576.4 = 3530.
Заявки AT000036 и AT000033 будут запланированы на Gladys Strong. Экран состояния заявок представлен на Рисунок 123. На экране состояния заявок
видно, что заявки AT000036 и AT000033 запланированы (статус Planned).
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 123 – Экран состояния заявок после планирования заявок
AT000036 и AT000033 на предпочитаемый ресурс Gladys Strong
Расписание после планирования заявок AT000036 и AT000033 представлено на Рисунок 124.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Рисунок 124 - Расписание после планирования заявок AT000036 и
AT000033 на предпочитаемый ресурс Gladys Strong
Таким образом, при сравнении результатов планирования, приведенных в
Таблица 23 и Таблица 25, можно сделать вывод о том, что выполнение неприбыльного заказа AT000036 совместно с заказом AT000033 увеличит общий KPI
системы, что позволит запланировать неприбыльный заказ.
5.8.3 Индивидуальные задания
1. Создайте две заявки и три ресурса. Последовательно запланируйте заявки. Создайте неприбыльную заявку. Наблюдайте, как изменится расписание
ресурсов, опишите полученные результаты. Проанализируйте основные показатели плана.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
5.9 Контрольные вопросы
1. Перечислите основные задачи системы управления мобильными ресурсами.
2. Перечислите основные особенности планирования ресурсов в транспортно-логистической компании.
3. Какие алгоритмы распределения ресурсов Вам известны? Опишите их
основные характеристики.
4. В чем заключаются особенности и преимущества мультиагентного
подхода к распределению ресурсов?
5. Что такое ПВ-сеть?
6. В чем заключается метод сопряженных взаимодействий?
7. В чем заключается метод компенсаций?
8. Назовите основные особенности метода адаптивного планирования.
9. Определелите понятие агента и перечислите основные характеристики
агентов.
10. Опишите конструкцию агента.
11. Опишите фазы жизненного цикла агента.
12. Перечислите основные характеристики известных мультиагентных архитектур.
13. Каковы отличительные особенности мультиагентной платформы для
системы управления транспортными ресурсами?
14. Опишите структуру онтологии транспортной логистики: основные
концепты и отношения.
15. Опишите основные функции агентнов МАС УТР.
16. Опишите алгоритмы и протоколы взаимодействия агентов МАС УТР.
17. Опишите логическую и физическую архитектуру МАС УТР.
18. Каковы преимущества адаптивного планирования для решения задач
управления транспортными ресурсами?
19. Какие основные показатели качества планирования, на основании которых агенты принимают решение, приняты в МАС УТР?
20. Опишите основные сценарии планирования заявок по ресурсам в МАС
УТР.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
ЗАКЛЮЧЕНИЕ
Адаптивное управление мобильными ресурсами в режиме реального времени на основе мультиагентного подхода позволяет планировать сложные процессы с множеством зависимостей, поскольку мультиагентный подход обеспечивает следующие преимущества:
­ улучшение
показателей
эффективности
работы
транспортноэкспедиционной компании за счет автоматического контроля местонахождения и автоматического контроля соблюдения расписания;
­ ускорение процессов долгосрочного и краткосрочного планирования перевозок;
­ контроль работы привлеченных транспортных ресурсов;
­ возможность получения оперативного среза работы ТЛК на любой момент
времени и снижение потерь рабочего времени и информации при взаимодействии служб и сотрудников.
Таким образом, рассматриваемая мультиагентная технология может быть
эффективно использована для создания сложных программных решений в области адаптивного планирования. При разработке и применении новых подходов к стратегическому и оперативному управлению ресурсами масштаба предприятия мультиагентная платформа позволит в значительной степени повысить
эффективность бизнеса компании и еѐ конкурентоспособность на рынке.
Большая часть задач, решаемых с помощью программных агентов в системе, сопряжена с поиском возможностей более эффективного использования
транспортных ресурсов, сокращением времени, затрачиваемого на принятие
решений, и поиском баланса между стоимостью и уровнем обслуживания. Положительный эффект, демонстрируемый ими на протяжении длительного времени на примере сложных транспортных сетей, доказывает их применимость
для решения задач планирования в различных промышленных сферах [86-88].
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Диязитдинова А.Р., Иващенко А.В., Мартышкин Д.М., Скобелев П.О.,
Сурнин О.Л., Царев А.В. Разработка мультиагентной платформы для
планирования в сфере транспортной логистики // Труды XI Международной конференции «Проблемы управления и моделирования в сложных
системах» Самара: Самарский научный центр РАН, 2009. – с. 608 – 623.
2. А.В. Вайсблат, А.Р. Диязитдинова, А.В. Иващенко, П.О. Скобелев, А.В.
Царев. Организация интерактивного взаимодействия в мультиагентной
системе управления транспортно-экспедиционной компанией // Труды
XII Международной конференции «Проблемы управления и моделирования в сложных системах» Самара: Самарский научный центр РАН, 2010.
– с. 620 – 628.
3. P. Skobelev, A.Glaschenko, I. Grachev, S. Inozemtsev Magenta Technology:
Case Studies of Magenta i-Scheduler for Road Transportation AAMAS’0, May
14-18, 2007, Honolulu, Hawaii, USA.
4. Himoff, J., Rzevski, G., Skobelev, P. Magenta Technology: Multi-Agent Logistics i-Scheduler for Road Transportation – Proceedings of The Fifth International Conference on Autonomous Agents and Multi Agent Systems (AAMAS
2006). – Japan, May 2006.
5. Rzevski, G., Skobelev, P. Agent Method and Computer System For Negotiating in a Virtual Environment, Patent No: WO 03/067432 A1. Published
14.08.2003.
6. Andreev M., Vinogradov P., Ivaschenko A., Nikolaev D., Skobelev P., Modern
principles of mobile resources management system implementation // Proceedings of the X international conference “Complex systems: Control and modeling problems” – Samara SSC of RAS, 2008 – pp. 420 – 425
7. Jacques, R. Recent Trends in Logistics and the Need for Real-time Decision
Tools in the Trucking Industry. Proceedings of the 34th Hawaii International
Conference on System Sciences, 2001.
8. Ann Arbor, Con-Way Transportation Launches New Kind of Logistics Service
With a `Shared Network' Approach to Solutions, Business Wire, Oct 20, 1998.
9. Головкин Б.А. Расчет характеристик и планирование параллельных вычислительных процессов. – М.: Радио и связь, 1983, 272 с.
10.M. Saleh, Z. Othman, and S. Shamala «FCFS Priority-based: An Adaptive Approach in Scheduling Real-Time Network Traffic» Networks and Communication Systems proceeding 527, 2006, ISBN 0-88986-590-6.
11.Marcia C. Cera, Guilherme P. Pezzi, Elton N. Mathias, Nicolas Maillard, Phillipe O.A. Navaux «Improving the Dynamic Creation of Processes in MPI-2»
Lecture Notes in Computer Science LNCS 4192 Recent Advantages in Parallel
Virtual Machine and Message Passing Interface, Volume 4192, pp. 247-255,
2006, ISBN-10: 3-540-39110-X ISBN-13: 978-3-540-39110-4.
12.S. Kirkpatrick and C. D. Gelatt and M. P. Vecchi, Optimization by Simulated
Annealing, Science, Vol 220, Number 4598, pages 671-680, 1983.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
13.Уссермен Ф. Нейрокомпьютерная техника. – М.: Мир, 1992.
14.Химмельблау Д. Прикладное нелинейное программирование. – М.: Мир,
1975.
15.Аоки М. Введение в методы оптимизации. – М.:Наука, 1977.
16.Сальников А.Н. Cистема разработки и поддержки исполнения параллельных программ// Диссертация на соискание учѐной степени кандидата физико-математических наук. Москва – 2006. УДК 519.682.3+519.687.1
17.Костенко В.А., Калашников А.В. Исследование различных модификаций
алгоритмов имитации отжига для решения задачи построения многопроцессорных расписаний// Дискретные модели в теории управляющих систем. Труды VII Международной конференции. М.: МАКС Пресс, 2006,
с.179-184.
18.Goldberg D.E. Genetic Algorithms in Search Optimizations and Machine
Learning.-Addison.Wesly, 1989.
19.Вороновский Г.К., Махотило К.В., Петрашев С.Н., Сергеев С.А. Генетические алгоритмы, искусственные нейронные сети и проблемы виртуальной реальности. – Харьков: Основа, 1997.
20.Сабанин В.Р., Смирнов Н.И, Репин А.И. Модифицированный генетический алгоритм для задач оптимизации в управлении. УДК 517.977.5.
21.Кофман А., Дебезей Г. Сетевые методы планирования и их применение. –
М. Прогресс, 1968.
22.Богданов Д.В., Казанцев О.В. Программные методы и средства планирования и управления проектами. Информационные технологии №2(22),
1997.
23.Долгий Э. Теория для победителя.
http://citforum.fast.net.ua/SE/project/victor_theory/.
24.http://ru.wikipedia.org/wiki/Интеллектуальный агент.
25.Леонид Витальевич Канторович: человек и ученый. В 2 т. Редакторысоставители В. Л. Канторович, С. С. Кутателадзе, Я. И. Фет. – Новосибирск: Изд-во СО РАН, Филиал «Гео», 2002, Т. 1.
26.Галеев Э.М., Тихомиров В.М. Оптимизация: теория, примеры, задачи,
2000.
27.Томас Х. Кормен и др. Глава 29. Линейное программирование // Алгоритмы: построение и анализ = INTRODUCTION TO ALGORITHMS. – 2-е
изд. – М.: «Вильямс», 2006.
28.Хемди А. Таха Глава 3. Симплекс-метод // Введение в исследование операций = Operations Research: An Introduction. – 7-е изд. – М.: «Вильямс»,
2007, с. 95-141.
29.http://ru.wikipedia.org/wiki/Линейное_программирование.
30.Круглов В. В., Борисов В. В. Искусственные нейронные сети. Теория и
практика. – М.: Горячая линия – Телеком, 2001.
31.В. А. Терехов, Д. В. Ефимов, И. Ю. Тюкин. Нейросетевые системы
управления. – Высшая школа, 2002. – С. 184.
32.Роберт Каллан Основные концепции нейронных сетей = The Essence of
Neural Networks First Edition. – М.: «Вильямс», 2001.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
33.M.Wooldridge and N.R.Jennings. Agent Theories, Architectures, and Languages: A Survey. In: Intelligent Agents. ECAI-94 Workshop on Agent Theories, Architecture and Languages. Amsterdam, The Netherlands, August 8-9,
1994, (Eds. M.J.Wooldridge and N.R.Jennings). Proceedings. Springer Verlag:
3-39, 1994.
34.Городецкий В.И., Грушинский М.С., Хабалов А.В. Многоагентные системы (обзор) // Новости искусственного интеллекта, №2, 1998, с. 64-116.
35.Андреев М.В., Батищев С.В., Искварина Т.В., Минаков И.А. Система
планирования расписания выставок. // Труды VI Всероссийской научной
конференции с международным участием «Новые информационные технологии. Разработка и аспекты применения». Таганрог: ООО «Антон»,
2003, с. 91-92.
36.Андреев М.В., Глащенко А.В., Иноземцев С.В., Киселев И.П., Сафронов
А.В., Скобелев П.О. Логика динамической балансировки трейд-оффов
агентов в задачах построения связанных расписаний в транспортной логистике реального времени. // Труды VIII-ой международной конференции «Проблемы управления и моделирования в сложных системах».
Самара: СНЦ РАН, 2006, с. 541-546.
37.Andreev M.V., Skobelev P.O., Shveykin P.K., Tsarev A.V., Tugashev A.A.
Adaptive Planning for Supply Chain Networks. // 3nd International Conference
on Industrial Applications of Holonic and Multi-Agent Systems September 3 5, 2007, Regensburg, Germany, pp. 215–224.
38.Mluller Jorg P. ''The design intelligence agents : a layered approach'' Springer
1996 (Lectures notes in computer science; vol. 1177 : Lectures notes in artifical intelligence) ISBN 3-540-62003-6.
39.Brooks, R. A., 1991, "Intelligence without Representation", Artificial Intelligence 47.
40.jade.tilab.com
41.vsis-www.informatik.uni-hamburg.de/projects/jadex/
42.Andreev M.V., Ivashchenko A.V., Skobelev P.O. Adaptive Multy-Agent Manufacturing Execution System. // Interactive Systems and Technologies: The
Problem of Human-Computer Interaction. – Collection of scientific papers. –
Ulyanovsk: UISTU, 2007, pp. 245-248.
43.Андреев В.В., Андреев М.В., Батищев С.В., Искварина М.В., Скобелев
П.О. Мультиагентный конструктор и планировщик транспортных сетей. //
Труды VI-ой международной конференции «Проблемы управления и моделирования в сложных системах». Самара: СНЦ РАН, 2004, с. 254-259.
44.В. Андреев, К. Ивкушкин, И. Минаков, Г. Ржевский, А. Сафронов, П.
Скобелев. Основные компоненты внутреннего устройства мультиагентной системы. // Труды 5-ой Международной конференции по проблемам
управления и моделирования сложных систем, Самара, 17-21 июня 2003.
– Самара: СНЦ РАН, 2003, с. 304 - 316.
45.В. Андреев, C. Батищев, К. Ивкушкин, Т. Искварина, П. Скобелев Инструментальные средства для разработки мультиагентных систем промышленного масштаба// Труды 6-ой Международной конференции по про-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
блемам управления и моделирования сложных систем, Самара, 14-17 июня 2004. - Самара: СНЦ РАН, 2004, с. 233 - 240.
46.Андреев В.В., Андреев М.В., Батищева М.В., Олейников А.В., Скобелев
П.О., Чевелѐв А.С. Конструкция агента в системах оперативного планирования и принятия решений. // Труды VII-ой международной конференции «Проблемы управления и моделирования в сложных системах».
Самара: СНЦ РАН, 2005, с. 414-420.
47.Handbook of Scheduling: Algorithms, Models and Performance Analysis.
Edited by J. Y-T. Leung // Chapman & Hall / CRC Computer and Information
Science Series. – 2004.
48.Leitao P., Barbosa J. Biological Inspiration to Solve Complexity in Intelligent
and Adaptive Manufacturing Systems / 10th IFAC Workshop on Intelligent
Manufacturing Systems (IMS'10). July 1-2, 2010 - Lisbon, Portugal. – pp. 221
– 226.
49.Bjelkemyr M., Neves P., Onori M. Evolutionary theories in manufacturing: inspiration from biology, society and evolutionary computing / 10th IFAC
Workshop on Intelligent Manufacturing Systems (IMS'10). July 1-2, 2010 Lisbon, Portugal. – pp. 227 – 232.
50.Valckenaers P. Enriching manufacturing with bio-inspiration: Reconciling the
complex-adaptive and the complicated / 10th IFAC Workshop on Intelligent
Manufacturing Systems (IMS'10). July 1-2, 2010 - Lisbon, Portugal. – pp. 379
– 380.
51.Skobelev P. Bio-inspired multi-agent technology in real time scheduling / 10th
IFAC Workshop on Intelligent Manufacturing Systems (IMS'10). July 1-2,
2010 - Lisbon, Portugal. – pp. 384 – 385.
52.П.О.Скобелев. Мультиагентные технологии в промышленных применениях: к 20-летию основания Самарской школы мультиагентных систем //
Мехатроника, Автоматизация, Управление. 2010. №12 – с.33-46.
53.Виттих В.А., Скобелев П.О. Метод сопряженных взаимодействий для
управления распределением ресурсов в реальном масштабе времени / Автометрия. – 2009. – № 2. – с. 78 – 87.
54.Виттих В.А., Мультиагентные модели взаимодействия для построения
сетей потребностей и возможностей в открытых системах [Текст] / В.А.
Виттих, П.О. Скобелев – М.: Автоматика и Телемеханика, 2003, №1, с.
177-185
55.Каляев И.А. Стратегии группового управления в распределенных системах / Материалы научно-технического семинара «Управление в распределенных сетецентрических и мультиагентных системах». СПб.: ОАО
«Концерн ЦНИИ «Электроприбор», 2010 – с. 8 – 9.
56.Капустян С.Г. Коллективное управление в распределенных сетецентрических системах / Материалы научно-технического семинара «Управление
в распределенных сетецентрических и мультиагентных системах». СПб.:
ОАО «Концерн ЦНИИ «Электроприбор», 2010 – с. 46 – 49.
57.Трахтенгерц Э.А. Компьютерная поддержка переговоров при согласовании управленческих решений М.: СИНТЕГ, 2003 – 284 с.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
58.Гаскаров Д.В. Интеллектуальные информационные системы. – М.: Высшая школа, 2003. – 431 с.
59.Mohania M., Bhide M., Roy P., Chakaravarthy V.T., Gupta H. Context
oriented information integration / Trans. on large-scale data and knowledge
centered systems I, LNCS 5740, pp 289 – 326, 2009. Springer-Verlag Berlin
Heidelberg.
60.Виттих В.А. Онтологический анализ и синтез при управлении открытыми
сложными системами / Труды V международной конференции «Проблемы управления и моделирования в сложных системах. Самара: СНЦ РАН.
– 2003. – с. 61 – 74.
61.O’Grady P., Young R.Y. Issues in concurrent engineering systems / Journal of
design and manufacturing, v.1 № 1. – 1991. – p. 27 – 34.
62.Виттих В.А. Онтологические модели ситуаций в процессах принятия
коллегиальных решений / Труды XI международной конференции «Проблемы управления и моделирования в сложных системах. Самара: СНЦ
РАН. – 2003. – с. 61 – 74.
63.Виттих В.А., Скобелев П.О. Мультиагентные модели взаимодействия для
построения сетей потребностей и возможностей в открытых системах /
М.: Автоматика и телемеханика. – 2003. – № 1. – с. 177 – 185.
64.Виттих В.А., Скобелев П.О. Метод сопряженных взаимодействий для
управления распределением ресурсов в реальном масштабе времени / М.:
Автометрия. – 2009. – № 2. – с. 78 – 87.
65.Agent Technology: Computing as Interaction. A Roadmap for Agent Based
Computing - http://www.agentlink.org/roadmap/index.html.
66.Wooldridge M. Intelligent agents: the key concepts // Multi-agent systems and
applications (ACAI 2001). – Springer Verlag. – 2002. – p. 3 – 43.
67.Городецкий В.И., Грушинский М.С., Хабалов А.В. Многоагентные системы / Новости искусственного интеллекта. 1998. № 2. С. 64 – 116.
68.Тарасов В.Б. От многоагентных систем к интеллектуальным организациям: философия, психология, информатика. М.: Эдиториал УРСС, 2002. 353 с.
69.Хорошевский В.Ф. Методы и средства проектирования и реализации
мультиагентных систем / Материалы семинара «Проблемы искусственного интеллекта». – М.: ИПУ РАН. – 1999.
70.Скобелев П.О. Теоретические основы создания открытых МАС для оперативной обработки информации в процессах принятия решений / Труды
V международной конференции «Проблемы управления и моделирования
в сложных системах. Самара: СНЦ РАН. – 2003. – с. 295 – 303.
71.Теряев Е.Д., Петрин К.В., Филимонов А.Б., Филимонов Н.Б. Агентные
технологии в автоматизированных информационно-управляющих системах. Часть 1. Основы агентного подхода / Мехатроника. Автоматизация.
Управление. – 2010. – № 7. – с 11 – 20.
72.Городецкий В.И., Карсаев О.В. Технология многоагентных систем и ее
приложения в управлении и моделировании / Труды V международной
конференции «Проблемы управления и моделирования в сложных систе-
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
мах. Самара: СНЦ РАН. – 2003. – с. 271 – 283.
73.Виттих В.А. Управление открытыми системами на основе интеграции
знаний // Автометрия, № 3. – 1999. – с. 38 – 49.
74.Bonabeau E., Theraulaz G. Swarm Smarts. What computers are learning from
them? / Scientific American. – 2000. - Vol. 282. - N 3. – P. 54-61.
75.Thompson, J. Ant Colony Optimisation / School of Mathematics - Cardiff
University, SWORDS, 2004.
76.Koestler. A. The Ghost in the Machine. Arkana, 1990.
77.Смирнов С.В. Онтологический анализ в системах компьютерного моделирования / Труды V международной конференции «Проблемы управления и моделирования в сложных системах. Самара: СНЦ РАН. – 2003. – с.
102 – 107.
78.Абрамов Д.В., Андреев В.В., Симонова Е.В., Скобелев П.О. Разработка
средств построения и использования онтологий для поддержки процессов
принятия решений / Труды VII международной конференции «Проблемы
управления и моделирования в сложных системах. Самара: СНЦ РАН. –
2005. – с. 435 – 440.
79.Виттих В.А., Волхонцев Д.В., Гинзбург А.Н., Караваев М.А., Скобелев
П.О., Сурнин О.Л., Шамашов М.А. Распределенные онтологии и их применение в решении задач интеграции данных / Труды VIII международной конференции «Проблемы управления и моделирования в сложных
системах. Самара: СНЦ РАН. – 2006. – с. 451 – 459.
80.Виноградов И.Д. Применение онтологического подхода к построению
интегрированных компьютерных моделей предприятий / Труды XI международной конференции «Проблемы управления и моделирования в
сложных системах. Самара: СНЦ РАН. – 2009. – с. 218 – 224.
81.Farquhar A., Fikes R., Rice J. The ontolingua server: A tool for collaborative
ontology construction // International Journal of Human-Computer Studies,
46(6), pages 707–728, 1997.
82.Musen, M. Domain Ontologies in Software Engineering: Use of Protégé with
the EON Architecture // Methods of Inform. in Medicine, pages 540-550,1998.
83.OntoEdit: Collaborative ontology development for the Semantic Web. Y. Sure,
M. Erdmann, J. Angele, S. Staab, R. Studer, D. Wenke // In Proc. of the Inter.
Semantic Web Conference (ISWC 2002), Sardinia, Italia, June 2002.
84.Bechhofer S.,Horrocks I., Goble C., Stevens R. OilEd: A Reason-able Ontology Editor for the Semantic Web // Joint German/Austrian conf. on Artificial Intelligence (KI’01). Lecture Notes in Artificial Intelligence LNAI 2174, Springer-Verlag, Berlin, pages.396-408, 2001.
85.Domingue J. Tadzebao and WebOnto: Discussing, Browsing, and Editing Ontologies on the Web // Proc. of the Eleventh Workshop on Knowledge Acquisition, Modeling and Management, KAW'98, Banff, Canada, 1998.
86.В.В.Андреев,
И.А.Минаков,
В.В.Пшеничников,
Е.В.Симонова,
П.О.Скобелев. Основы построения мультиагентных систем. – Учебное
пособие. – Самара: ПГАТИ, 2007. -151 с.
87.Д.В.Абрамов, В.В.Андреев, Е.В.Симонова, П.О.Скобелев. Открытые
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
мультиагентные системы для принятия решений в задачах динамического
распределения ресурсов. - Учебное пособие. - Самара: ПГАТИ, 2008. 290 с.
88.М.В. Андреев, А.В.Иващенко, Е.В.Симонова, П.О.Скобелев, А.В.Царев.
Автоматизация адаптивного управления производством на промышленном предприятии. – Учебное пособие. – Самара: ПГУТИ, 2009. – 184 с.
Copyright ОАО «ЦКБ «БИБКОМ» & ООО «Aгентство Kнига-Cервис»
Учебное издание
Иващенко Антон Владимирович
Лада Александр Николаевич
Симонова Елена Витальевна
Скобелев Петр Олегович
Мультиагентная технология управления мобильными ресурсами
в режиме реального времени
Учебное пособие
Печатается в авторской редакции
Подписано в печать ____________. Формат 60х84 1/16
Бумага офсетная. Печать офсетная.
Усл. печ. л. ____. Усл. кр.-отт. ____. Уч.-изд. л. ____.
Тираж _______ экз. Заказ _______. Арт.С-_______/_____.
Поволжский государственный университет
телекоммуникаций и информатики
443010, г. Самара ул. Льва Толстого, 23
Издательство Поволжского государственного университета
телекоммуникаций и информатики
443010, г. Самара, ул. Льва Толстого, 23
Документ
Категория
Без категории
Просмотров
96
Размер файла
10 360 Кб
Теги
времени, режим, мультиагентной, 10131, технология, реального, управления, ресурсами, мобильный
1/--страниц
Пожаловаться на содержимое документа