close

Вход

Забыли?

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

?

Andreev Ivachenko Simonova Skobelev Zarev Avtomatizaziya adaptivnogo upravleniya

код для вставкиСкачать
Министерство связи и массовых коммуникаций
Российской Федерации
Государственное образовательное учреждение
высшего профессионального образования
ПОВОЛЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ТЕЛЕКОММУНИКАЦИЙ И ИНФОРМАТИКИ
ЭЛЕКТРОННАЯ БИБЛИОТЕЧНАЯ
СИСТЕМА
Самара
ФЕДЕРАЛЬНОЕ АГЕНТСТВО СВЯЗИ
ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ
ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ
«ПОВОЛЖСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ
ТЕЛЕКОММУНИКАЦИЙ И ИНФОРМАТИКИ» (ПГУТИ)
НАУЧНО-ПРОИЗВОДСТВЕННАЯ КОМПАНИЯ «ГЕНЕЗИС ЗНАНИЙ»
Кафедра инженерии знаний
М.В.Андреев, А.В.Иващенко, Е.В.Симонова,
П.О.Скобелев, А.В. Царев
АВТОМАТИЗАЦИЯ АДАПТИВНОГО
УПРАВЛЕНИЯ ПРОИЗВОДСТВОМ
НА ПРОМЫШЛЕННОМ ПРЕДПРИЯТИИ
Учебное пособие
САМАРА 2009
2
УДК 004.9 (075)
ББК 32.97
Автоматизация адаптивного управления производством на
промышленном предприятии / М.В.Андреев, А.В.Иващенко,
Е.В.Симонова, П.О.Скобелев, А.В. Царев. Поволжский
государственный
университет
телекоммуникаций
и
информатики. Самара, 2009 – 184 с.
ISBN
Учебное пособие предназначено для студентов, обучающихся
по специальности 230105 – «Программное обеспечение вычислительной техники и автоматизированных систем». Рекомендуется использовать учебное пособие при изучении курсов «Системы
искусственного интеллекта», «Мультиагентные системы» и
«Мультиагентный подход в управлении распределенными системами». Включает разделы, которые подробно описывают современное состояние и методы производственного планирования,
мультиагентный подход к решению задач планирования и распределения производственных ресурсов, архитектуру и реализацию автоматизированной системы планирования производства.
Теоретический материал иллюстрируется большим количеством
примеров динамического планирования. Учебное пособие содержит контрольные вопросы и упражнения по всем разделам.
Учебное пособие разработано на кафедре инженерии знаний
совместно с Научно-производственной компанией «Генезис знаний». В настоящее время данные разработки выполняются в ООО
НПК «Разумные решения». Рассматриваемая мультиагентная
система и лабораторный практикум не могут копироваться или
воспроизводиться в любых формах без специального разрешения.
Табл. 57. Ил. 150. Библиогр.: 75 назв.
Печатается по решению редакционно-издательского совета Поволжского государственного университета телекоммуникаций и
информатики
Рецензенты: д.т.н., проф. Прохоров С.А.
д.т.н., проф. Смирнов С.В.
ISBN
© Поволжский государственный университет
телекоммуникаций и информатики, 2009
3
СОДЕРЖАНИЕ
Введение ................................................................................................................. 9
1 Методы и алгоритмы построения производственного плана ........................ 12
1.1 Обзор автоматизированных систем распределения
производственных ресурсов современных промышленных
предприятий ........................................................................................................ 12
1.1.1 Общая классификация систем автоматизированного
управления ....................................................................................................... 12
1.1.2 Современные системы распределения производственных
ресурсов ............................................................................................................ 14
1.1.3 Современное состояние MES-систем ................................................... 16
1.1.4 Системы распределения производственных ресурсов как
сложные системы............................................................................................. 23
1.1.5 Классификация систем распределения производственных
ресурсов ............................................................................................................ 26
1.2 Обзор алгоритмов распределения производственных ресурсов ............. 31
1.2.1 Списочные алгоритмы ........................................................................... 31
1.2.2 Алгоритм имитации отжига .................................................................. 32
1.2.3 Генетические алгоритмы ....................................................................... 33
1.2.4 Алгоритм поиска критического пути (CPM) и метод оценки и
анализа программ (PERT) ............................................................................... 34
1.2.5 Линейное программирование и симплекс метод ................................ 36
1.2.6 Нейронные сети ...................................................................................... 37
1.2.7 Мультиагентный подход ....................................................................... 38
1.2.8 Анализ алгоритмов распределения производственных
ресурсов ............................................................................................................ 40
2 Мультиагентная модель плана производства.................................................. 45
2.1 Задачи планирования производства ........................................................... 45
2.2 Мультиагентная модель плана .................................................................... 46
2.3 Мультиагентный алгоритм планирования ................................................. 52
3 Автоматизированная система адаптивного планирования
производства .......................................................................................................... 59
3.1 Обзор архитектуры мультиагентных систем............................................. 59
3.2 Архитектура автоматизированной системы адаптивного
планирования производства .............................................................................. 61
3.3 Интерфейс автоматизированной системы адаптивного
планирования производства .............................................................................. 65
3.3.1 Основной инструментарий .................................................................... 65
3.3.2 Онтология ................................................................................................ 76
3.4 Пример типового использования автоматизированной системы
планирования производства .............................................................................. 80
4
4 Цели, задачи и содержание лабораторного практикума ................................ 89
5 Лабораторная работа №1. Построение плана согласованных
мероприятий и использования оборудования на производственном
предприятии ........................................................................................................... 91
5.1 Цели и задачи лабораторной работы .......................................................... 91
5.2 Онтология планирования мероприятий ..................................................... 91
5.3 Сценарий распределения ресурсов со свободным расписанием ............. 94
5.3.1 Описание сценария ................................................................................. 94
5.3.2 Начальное состояние сцены .................................................................. 94
5.3.3 Этапы проведения эксперимента .......................................................... 95
5.4 Сценарий распределения ресурсов с интервалом недоступности
ресурса ................................................................................................................. 97
5.4.1 Описание сценария ................................................................................. 97
5.4.2 Начальное состояние сцены .................................................................. 97
5.4.3 Этапы проведения эксперимента .......................................................... 98
5.4.4 Индивидуальные задания ...................................................................... 100
5.5 Сценарий планирования со сдвигом длинной цепочки операций .......... 100
5.5.1 Описание сценария ................................................................................. 100
5.5.2 Начальное состояние сцены .................................................................. 100
5.5.3 Этапы проведения эксперимента .......................................................... 102
5.5.4 Индивидуальные задания ...................................................................... 104
5.6 Сценарий планирования задач с предшественниками ............................. 104
5.6.1 Описание сценария ................................................................................. 104
5.6.2 Начальное состояние сцены .................................................................. 104
5.6.3 Этапы проведения эксперимента .......................................................... 105
5.7 Сценарий планирования задач с подзадачами .......................................... 107
5.7.1 Описание сценария ................................................................................. 107
5.7.2 Начальное состояние сцены .................................................................. 108
5.7.3 Этапы проведения эксперимента .......................................................... 109
5.8 Сценарий планирования с выбрасыванием менее важных задач............ 110
5.8.1 Описание сценария ................................................................................. 110
5.8.2 Начальное состояние сцены .................................................................. 110
5.8.3 Этапы проведения эксперимента .......................................................... 111
5.8.4 Индивидуальные задания ...................................................................... 112
5.9 Сценарий с проактивностью агента операции .......................................... 112
5.9.1 Описание сценария ................................................................................. 112
5.9.2 Начальное состояние сцены .................................................................. 113
5.9.3 Этапы проведения эксперимента .......................................................... 113
5.10 Сценарий, демонстрирующий понятие реального и модельного
времени в онтологии .......................................................................................... 116
5.10.1 Описание сценария ............................................................................... 116
5.10.2 Начальное состояние сцены ................................................................ 116
5.10.3 Этапы проведения эксперимента ........................................................ 117
5.10.4 Индивидуальные задания .................................................................... 118
5
5.11 Сценарий, демонстрирующий использование времени
заморозки............................................................................................................. 118
5.11.1 Описание сценария ............................................................................... 118
5.11.2 Начальное состояние сцены ................................................................ 119
5.11.3 Этапы проведения эксперимента ........................................................ 119
5.12 Сценарий, демонстрирующий режим подтверждения задачи............... 120
5.12.1 Описание сценария ............................................................................... 120
5.12.2 Начальное состояние сцены ................................................................ 120
5.12.3 Этапы проведения эксперимента ........................................................ 122
5.13 Сценарий с изменением предпочитаемого времени /
минимального / максимального времени начала задачи ................................ 123
5.13.1 Описание сценария ............................................................................... 123
5.13.2 Начальное состояние сцены ................................................................ 123
5.13.3 Этапы проведения эксперимента ........................................................ 124
5.14 Сценарий планирования задач с перемещением операций на
удобное время ..................................................................................................... 127
5.14.1 Описание сценария ............................................................................... 127
5.14.2 Начальное состояние сцены ................................................................ 127
5.14.3 Этапы проведения эксперимента ........................................................ 127
5.14.4 Индивидуальные задания .................................................................... 128
5.15 Сценарий с предложением пользователю вариантов разрешения
конфликтных ситуаций ...................................................................................... 129
5.15.1 Описание сценария ............................................................................... 129
5.15.2 Начальное состояние сцены ................................................................ 129
5.15.3 Этапы проведения эксперимента ........................................................ 130
5.15.4 Индивидуальные задания .................................................................... 131
5.16 Контрольные вопросы ............................................................................... 132
6 Лабораторная работа №2. Планирование технологического процесса
производства на основе знаний, представленных в Онтологии ....................... 133
6.1 Цели и задачи лабораторной работы .......................................................... 133
6.2 Онтология производства.............................................................................. 133
6.3 Сценарий поиска ресурсов для задачи ....................................................... 138
6.3.1 Описание сценария ................................................................................. 138
6.3.2 Начальное состояние сцены .................................................................. 138
6.3.3 Этапы проведения эксперимента .......................................................... 138
6.3.4 Индивидуальные задания ...................................................................... 140
6.4 Сценарий планирования с учетом требований к ресурсам,
заданных в онтологии ........................................................................................ 140
6.4.1 Описание сценария ................................................................................. 140
6.4.2 Начальное состояние сцены .................................................................. 140
6.4.3 Этапы проведения эксперимента .......................................................... 141
6.4.4 Индивидуальные задания ...................................................................... 142
6.5 Сценарий планирования сложной задачи на основе ее описания в
онтологии ............................................................................................................ 143
6
6.5.1 Описание сценария ................................................................................. 143
6.5.2 Начальное состояние сцены .................................................................. 143
6.5.3 Этапы проведения эксперимента .......................................................... 144
6.5.4 Индивидуальные задания ...................................................................... 147
6.6 Сценарий планирования задач с вытеснением запланированной
задачи на другой ресурс ..................................................................................... 148
6.6.1 Описание сценария ................................................................................. 148
6.6.2 Начальное состояние сцены .................................................................. 148
6.6.3 Этапы проведения эксперимента .......................................................... 148
6.6.4 Индивидуальные задания ...................................................................... 150
6.7 Сценарий планирования задач с проактивностью ресурса ...................... 150
6.7.1 Описание сценария ................................................................................. 150
6.7.2 Начальное состояние сцены .................................................................. 150
6.7.3 Этапы проведения эксперимента .......................................................... 151
6.7.4 Индивидуальные задания ...................................................................... 152
6.8 Контрольные вопросы.................................................................................. 152
7 Лабораторная работа №3. Изучение виртуального рынка в задачах
адаптивного планирования технологического процесса производства .......... 153
7.1 Цели и задачи лабораторной работы .......................................................... 153
7.2 Модели микроэкономики ............................................................................ 153
7.2.1 Расчет физической стоимости выполнения операций........................ 153
7.2.2 Модели логики принятия решений ...................................................... 155
7.3 Сценарий демонстрации микроэкономических характеристик
ресурсов ............................................................................................................... 157
7.3.1 Описание сценария ................................................................................. 157
7.3.2 Начальное состояние сцены .................................................................. 157
7.3.3 Этапы проведения эксперимента .......................................................... 158
7.4 Сценарий демонстрации микроэкономических характеристик
взаимосвязанных ресурсов ................................................................................ 160
7.4.1 Описание сценария ................................................................................. 160
7.4.2 Начальное состояние сцены .................................................................. 160
7.4.3 Этапы проведения эксперимента .......................................................... 161
7.5 Сценарий планирования задачи «Изготовить зеркало заднего
вида» .................................................................................................................... 163
7.5.1 Описание сценария ................................................................................. 163
7.5.2 Начальное состояние сцены .................................................................. 163
7.5.3 Этапы проведения эксперимента .......................................................... 164
7.5.4 Индивидуальные задания ...................................................................... 166
7.6 Сценарий планирования задачи «Изготовить изделие Болт-728» .......... 166
7.6.1 Описание сценария ................................................................................. 166
7.6.2 Начальное состояние сцены .................................................................. 166
7.6.3 Этапы проведения эксперимента .......................................................... 168
7.6.4 Индивидуальные задания ...................................................................... 170
7.7 Сценарий демонстрации логики принятия решения при
7
выполнении задачи «Изготовить два изделия Болт-728» .............................. 171
7.7.1 Описание сценария ................................................................................. 171
7.7.2 Начальное состояние сцены .................................................................. 171
7.7.3 Этапы проведения эксперимента .......................................................... 172
7.8 Сценарий демонстрации распределения ресурсов с изменением
стратегии планирования при выполнении задачи «Изготовить два
зеркала заднего вида» ........................................................................................ 178
7.8.1 Описание сценария ................................................................................. 178
7.8.2 Начальное состояние сцены .................................................................. 179
7.8.3 Этапы проведения эксперимента .......................................................... 179
7.9 Сценарий планирования с изменением описания
технологического процесса в онтологии ......................................................... 183
7.9.1 Описание сценария ................................................................................. 183
7.9.2 Минимальные требования для работы сценария ................................ 183
7.9.3 Начальное состояние сцены .................................................................. 183
7.9.4 Этапы проведения эксперимента .......................................................... 184
7.10 Контрольные вопросы ............................................................................... 195
Заключение ............................................................................................................ 196
Библиографический список ................................................................................. 198
8
ВВЕДЕНИЕ
Управление современным производственным предприятием связано с необходимостью решения многих сложных задач организации производственных
процессов и подготовки производства, планирования и организации управления
производством, управления производственными ресурсами и кадрами. С учетом современных требований по автоматизации всех этапов жизненного цикла
изделия, включающего и процесс производства, в управлении современными
предприятиями широко используются автоматизированные системы управления и поддержки принятия решений.
Эти системы обычно классифицируют по выполняемым функциям: это
системы инженерной подготовки производства и управления жизненным циклом изделия (PDM/PLM), системы управления ресурсами (ERP), системы автоматизированного проектирования, финансового и бухгалтерского учета и другие. В частности, весьма востребованными являются производственные исполнительные (MES) системы, основным назначением которых является автоматизация планирования и управления производством.
Системы планирования и управления производством имеют достаточно
уникальное положение, что определяет их высокую важность в едином информационном пространстве предприятия. С одной стороны, они имеют доступ к
знаниям о производственных ресурсах, обработка которых ведется в ERP системе. С другой стороны, они обладают актуальными данными о текущем статусе производственного процесса. Именно благодаря такому положению этим
системам на многих предприятиях отводится главная роль, а, следовательно, в
условиях высокой динамики развития предприятий, к ним предъявляются особые требования.
В частности, для обеспечения эффективной автоматизации управления
производством необходимо обеспечить автоматизацию планирования производственных ресурсов в реальном времени. Для этого требуется применение
новых алгоритмов, которые позволяют за ограниченное время найти оптимальное решение. При этом в ходе планирования и собственно управления производством могут меняться критерии и ограничения, а каждый из многочисленных объектов и субъектов планирования может иметь индивидуальную логику
принятия решений.
Такая картина наиболее точно отражает реальный мир, в котором план
производства строится в процессе непрерывного согласования, разрешения
конфликтов и поиска компромиссов между лицами, принимающими решения,
которые отвечают за разные аспекты деятельности предприятия: технологов,
мастеров, экономистов и др.
В связи с тем, что многие из хорошо известных и апробированных автоматизированных систем планирования производства не могут обеспечить соответствие указанным требованиям, крайне актуальной является разработка и
реализация новых алгоритмов автоматизированного планирования производства. В данном пособии предлагается использование мультиагентных технологий,
9
хорошо зарекомендовавших себя при решении задач планирования ресурсов в
реальном времени и позволяющих обеспечить требуемые новые возможности.
Мультиагентные алгоритмы планирования ресурсов базируются на новом
подходе к описанию и моделированию сложных систем. В отличие от классических MES систем, в мультиагентной системе внутрицехового планирования
каждое предприятие моделируется как динамическая сеть программных агентов потребностей и возможностей. В такой сети могут быть представлены различные подразделения, конкретные производственные заказы (на готовое изделие или его компоненты, отдельную операцию станка и т.д.) и конкретные ресурсы (например, рабочие, детали или станки).
Главной задачей такой системы является построение и поддержание баланса интересов всех участников производственного процесса. Для такого рода
систем становится характерным переход от централизованных решений к распределенным; замена иерархий на сетевую организацию, команд-инструкций
«сверху-вниз» – на переговоры равноправных сторон, жестких планов – на гибкие планы, фиксированных цен – на договорные и т.д. В условиях современной
экономики эти принципы обеспечивают более высокую гибкость и эффективность управленческих решений.
В ходе процесса переговоров агентов производится построение квазиоптимального, сбалансированного по многим критериям плана производства с
учетом индивидуальных ограничений и предпочтений, а также целей предприятия в целом. В случае возникновения непредвиденных событий (поломка
станка, опоздание рабочего), агенты могут динамически, в режиме реального
времени, перераспределить задания на другие доступные ресурсы, без пересмотра всего плана производства.
Агенты потребностей и возможностей взаимодействуют следующим образом. Заказы и ресурсы могут вступать в непосредственные связи между собой
и инициировать процесс взаимного пересмотра и согласования планов по мере
возникновения ожидаемых или заранее непредвиденных событий с каждым из
этих элементов (новый более выгодный заказ, отзыв уже принятого заказа, новый станок, поломка станка и т.д.). За счет такой динамической сетевой организации разрабатываемая система в любой момент времени может пересматривать связи между этими элементами и согласованно менять их планы. Таким
образом, обеспечивается автоматическое гибкое планирование ресурсов предприятия в реальном времени, как в автоматическом режиме, так и в диалоге с
человеком.
Такой подход является незаменимым на практике для управления производством сложных изделий в реальном времени, требующим учета множества
индивидуальных особенностей производства каждого элемента в условиях заранее непредсказуемых изменений спроса и предложения. Распределенное планирование обладает большей гибкостью в том смысле, что планирование осуществляется не перестройкой всего плана, а локальным изменением только тех
частей плана, которые действительно необходимо модифицировать.
Другим важным свойством, являющимся следствием распределенного
10
планирования, является адаптивность. Построение локальных изменений производится не по жесткому централизованному алгоритму, а является результатом совместной работы отдельных агентов, учитывающих свои состояния и
действующих по обстоятельствам.
Данное пособие содержит сведения, необходимые для понимания основ
построения мультиагентных систем планирования производства в реальном
времени и понимания механизма работы мультиагентных алгоритмов и основные особенностей их применения. Пособие содержит теоретический материал и
лабораторный практикум, для освоения которого необходимы начальные знания основ управления сложными системами и программирования, а также базовые навыки построения мультиагентных систем управления предприятием.
При проведении лабораторного практикума рекомендуется использовать
учебную версию автоматизированной системы адаптивного планирования мелкосерийного производства (краткое название – АС адаптивного планирования
производства).
Авторы выражают надежду, что представленный материал станет отправной точкой в интереснейшем пути изучения и дальнейшего применения мультиагентных технологий в задачах автоматизации производственного планирования и управления различными ресурсами в реальном времени. Данное пособие можно рекомендовать как студентам вузов, так и инженерам, занимающимся созданием и внедрением новых технологий планирования и управления производством.
11
1 МЕТОДЫ И АЛГОРИТМЫ ПОСТРОЕНИЯ
ПРОИЗВОДСТВЕННОГО ПЛАНА
1.1 Обзор автоматизированных систем распределения
производственных ресурсов современных промышленных
предприятий
1.1.1 Общая классификация систем автоматизированного
управления
Существует множество критериев, по которым можно классифицировать
системы автоматизированного управления [1]. Одним из показателей для разделения систем управления на два класса можно назвать наличие или отсутствие обратной связи:
­ разомкнутые (незамкнутые) – процесс работы системы не зависит непосредственно от результата ее воздействия на управляемый объект, т.е. в ней отсутствует обратная связь;
­ замкнутые – характерной особенностью этой системы является наличие обратной связи, благодаря которой информация о состоянии управляемого
объекта передается в управляющее устройство. Данный тип систем управления является естественным дальнейшим усовершенствованием автоматической системы.
По виду задающего воздействия можно выделить следующие типы:
­ системы стабилизации – в данном типе систем задающее воздействие константно, то есть постоянно. Цель данных систем – поддержание постоянства
некоторого физического параметра;
­ системы программного управления – в случае, если задающее воздействие
изменяется по какому–либо заранее известному закону. В качестве примера
можно привести повышение температуры при термической обработке изделий;
­ следящие системы – задающее воздействие в этом случае заранее неизвестно
и определяется внешними факторами (например, в радиолокационной станции слежения за самолетом задающее воздействие определяется движением
наблюдаемого самолета).
Другим критерием классификации можно назвать вид сигнала на выходе
элементов системы управления. При этом системы управления подразделяются
следующим образом:
­ непрерывные – системы управления, в которых выходные переменные всех
элементов являются непрерывными функциями;
­ дискретные – системы управления, в которых хотя бы одна выходная переменная какого-либо элемента принимает дискретные значения по значению
и/или по времени.
По зависимости характеристик системы управления от времени различают:
12
­ стационарные – характеристики системы управления не зависят от времени;
­ нестационарные – характеристики системы управления зависят от времени.
Наиболее актуальным в настоящее время все более становится деление
систем управления в зависимости от использования текущей информации:
­ обычные (или неадаптивные) – если текущая информация используется
только для выработки управляющего воздействия при неизменном алгоритме управления;
­ адаптивные – если текущая информация используется также для изменения
алгоритма управления и/или задающего воздействия.
Адаптивные системы можно разделить на следующие типы:
­ оптимальные – обеспечивают автоматическое поддержание в объекте управления наилучшего режима;
­ самонастраивающиеся – в данных системах управления адаптация достигается изменением параметров;
­ самоорганизующиеся – системы управления, в которых адаптация достигается изменением параметров, а также и структуры управляющей системы;
­ системы с адаптацией в особых фазовых состояниях – в данных системах
специально организуются особые режимы (например, режим автоколебаний), которые служат еще одним источником рабочей информации об изменяющихся характеристиках объекта или придают системе новые свойства, за
счет которых динамические характеристики управляемого процесса поддерживаются в допустимых пределах, независимо от изменений условий работы
системы;
­ самообучающиеся – используют процессы обучения: постепенное накапливание, запоминание и анализ накопленного опыта управления объектом. На
основании этого система управления совершенствует свою структуру и способ управления. Такие системы повышают качество управления по мере
эксплуатации.
В зависимости от характера внешних и внутренних воздействий различают детерминированные и стохастические системы управления. Стохастической системой управления называется такая система, у которой хотя бы одно
воздействие является стохастическим, то есть случайным. Иначе система называется детерминированной.
Кроме перечисленных критериев, можно также указать деление на основе
типов уравнений, которыми описываются системы управления, т.е. линейные
и нелинейные. Если система управления описывается линейными уравнениями,
такая система называет линейной, если описывается нелинейными уравнениями
– нелинейной.
Как указывается в различной литературе, в частности, в [1], «При исследовании, расчете и синтезе автоматических систем нужно иметь в виду, что
наиболее полно разработаны теория и различные прикладные методы для
обыкновенных линейных и линейных дискретных систем. Поэтому в интересах
простоты расчета всегда желательно (там, где это допустимо) сводить задачу к
такой форме, чтобы максимально использовать методы исследования таких
13
систем. Обычно уравнения динамики всех звеньев системы стараются привести
к обыкновенным линейным, и только для некоторых звеньев, где это недопустимо или где специально вводится особое линейное или нелинейное звено, учитываются эти особые их свойства. Тогда при наличии одного такого звена система при расчете разбивается на два блока, в одном из которых объединяется
весь комплекс обыкновенных линейных звеньев.
Однако это вовсе не значит, что при проектировании новых автоматических систем нужно стремиться к обыкновенным линейным системам. Наоборот, уже из приведенных выше определений совершенно очевидно, что обыкновенные линейные системы обладают ограниченными возможностями. Введение особых линейных и нелинейных звеньев может придать системе лучшие
качества. Особенно богатыми возможностями обладают системы со специально
вводимыми нелинейностями и дискретные системы, в том числе с цифровыми
вычислительными устройствами, а также адаптивные системы».
1.1.2 Современные системы распределения производственных
ресурсов
Сложность управления современным машиностроительным предприятием приводит к необходимости применения новых подходов к организации производства, обеспечивающих высокий уровень качества и конкурентоспособности изделий. Большие возможности для настройки как оборудования, так и технологии производства позволяют выйти на более высокий уровень эффективности работы предприятия, при условии правильной настройки данных параметров. Однако это приводит к сильному усложнению логики выбора режимов
и времени принятия решения руководителями предприятия.
Одним из главных методов решения этой проблемы является применение
автоматизации, что приводит к повышению эффективности работы предприятия. Можно выделить различные уровни автоматизации предприятия [2]:
­ для руководства – ERP-система (Enterprise Resource Planning) – корпоративная информационная система (КИС), предназначенная для автоматизации
учѐта и управления. Как правило, ERP-системы строятся по модульному
принципу и в той или иной степени охватывают все ключевые процессы
деятельности компании, в том числе управление сбытом, закупками, финансами, бухгалтерией, кадрами.
­ для инженера-технолога – автоматизированная система управления технологическим процессом (АСУ ТП) – комплекс программных и технических
средств, предназначенный для управления технологическим оборудованием
на предприятиях
­ для конструкторов – система автоматизации проектных работ (САПР) – организационно-техническая система, предназначенная для выполнения проектной деятельности с применением вычислительной техники, позволяющая
создавать конструкторскую и/или технологическую документацию.
В настоящее время все больший интерес вызывает новый класс систем
управления производством – MES (Manufacturing Execution System – производ14
ственные исполнительные системы) [3, 4, 5].
Международная ассоциация производителей систем управления производством MESA [6] определяет понятие MES-системы следующим образом:
«...Система, состоящая из набора программных и аппаратных средств, обеспечивающих функции управления производственной деятельностью – от заказа
на изготовление партии продукции и до завершения производства. Используя
своевременные и точные данные, MES инициирует, ведет, реагирует на изменяющуюся ситуацию и составляет отчеты о производственных процессах по
мере их протекания. Эта система позволяет обмениваться информацией о производственных процессах с другими инженерными и бизнес-подразделениями
предприятия и цепочками его поставок через двунаправленные каналы связи».
MESA определила одиннадцать типовых обобщенных функций MES систем:
­ Контроль состояния и распределение ресурсов (RAS) – Управление ресурсами производства: технологическим оборудованием, материалами, персоналом, документацией, инструментами, методиками работ.
­ Оперативное/Детальное планирование (ODS) – Расчет производственных
планов, основанный на приоритетах, атрибутах, характеристиках и способах,
связанных со спецификой изделий и технологией производства.
­ Диспетчеризация производства (DPU) – Управление потоком изготавливаемых деталей по операциям, заказам, партиям, сериям, посредством рабочих
нарядов.
­ Управление документами (DOC) – Контроль содержания и прохождения документов, сопровождающих изготовление продукции, ведение плановой и
отчетной цеховой документации.
­ Сбор и хранение данных (DCA) – Взаимодействие информационных подсистем в целях получения, накопления и передачи технологических и управляющих данных, циркулирующих в производственной среде предприятия.
­ Управление персоналом (LM) – Обеспечение возможности управления персоналом в ежеминутном режиме.
­ Управление качеством продукции (QM) – Анализ данных измерений качества продукции в режиме реального времени на основе информации, поступающей с производственного уровня, обеспечение должного контроля качества, выявление критических точек и проблем, требующих особого внимания.
­ Управление производственными процессами (PM) – Мониторинг производственных процессов, автоматическая корректировка либо диалоговая поддержка решений оператора.
­ Управление техобслуживанием и ремонтом (MM) – Управление техническим обслуживанием, плановым и оперативным ремонтом оборудования и
инструментов для обеспечения их эксплуатационной готовности.
­ Отслеживание истории продукта (PTG) – Визуализация информации о месте
и времени выполнения работ по каждому изделию. Информация может
включать отчеты: об исполнителях, технологических маршрутах, комплек15
тующих, материалах, партионных и серийных номерах, произведенных переделках, текущих условиях производства и т.п.
­ Анализ производительности (PA) – Предоставление подробных отчетов о
реальных результатах производственных операций, сравнение плановых и
фактических показателей.
Так как автоматизацию предприятия необходимо производить в различных областях, то целесообразно автоматизировать в первую очередь ту часть,
которая приносит основной доход предприятию.
В работе [7] делаются следующие выводы:
­ Прибавочная стоимость продукции создается в производственных зонах (цехах, участках), поэтому инвестиции в повышение эффективности производственных процессов дают реальную отдачу.
­ Достоверная и своевременная информация, необходимая для принятия правильных решений, находится в производственных зонах.
­ Оптимизация управления технологическими процессами способна реально
изменить финансовые показатели предприятия.
­ Прибыльность и эффективность предприятия зависит от людей в производственных зонах, возможности которых многократно усиливаются с помощью MES системы.
­ При обнаружении критических и нештатных ситуаций в производственных
зонах MES системы быстро анализируют информацию и оперативно предлагают корректирующие решения.
­ Именно производственные зоны определяют конкурентоспособность предприятия, возможность его быстрой переналадки на изменение требований со
стороны потребителей.
Таким образом, автоматизацию производственных предприятий целесообразно проводить в первую очередь MES системами.
Однако выбор MES системы и ее внедрение часто затруднены из-за необходимости задания множества различных критериев составления и оптимизации производственных планов. Необходимость постоянной доработки системы
под конкретное предприятие при ориентации на мелкосерийное производство
оказывается довольно сильным аргументом для поиска новых методов управления планом производства в MES системах.
1.1.3 Современное состояние MES-систем
Среди множества MES-систем наиболее популярными являются Фобос
[8, 9, 10], Omega Production [11], YSB.Enterprise.Mes [12], PolyPlan [13], Zenith
SPPS [14], T-FACTORY 6 [15], Preactor [16] и отчасти Axapta [17]. Рассмотрим
их более подробно.
Одним из модулей российской системы ФОБОС оказывающих наибольшее влияние на построение плана производства, является Оперативное планирование и контроль (ОПК). Данный модуль является ядром интегрированной
системы ФОБОС. Оперативное планирование и диспетчерский контроль прохождения заказов осуществляется в системе посредством расчета оптимального
16
производственного плана. В основу расчета и управления планом положен математический оптимизационный аппарат, позволяющий моделировать 100 сценариев по 14 критериям. ФОБОС предоставляет следующую функциональность
[18]:
­ формирование и коррекция оперативных производственных планов цеха с
учетом имеющихся межоперационных заделов и текущего состояния станочной системы;
­ расчет производственного расписания загрузки оборудования по различным
критериям (100 комбинаций из 14 критериев);
­ представление результатов расчета расписания в виде таблиц текущего состояния партий запуска, графиков обработки партий деталей и диаграмм загрузки оборудования;
­ формирование сменно-суточных заданий на рабочие места цеха;
­ формирование оперативных маршрутных карт по всем партиям запуска с
контролем их прохождения по рабочим местам;
­ составление и автоматическая коррекция планово-учетного графика изготовления комплектов деталей с контролем готовности каждой партии запуска;
­ автоматизированный контроль состояния производственного процесса и
имитационное моделирование материальных потоков в цехе (на участке);
­ расчет времени простоя оборудования и пролеживания деталей;
­ формирование рабочих нарядов на выполненные и текущие технологические
операции, контроль процесса выдачи нарядов в соответствии с производственным планом;
­ печать внутрицеховых документов: сменно-суточные задания на рабочие
места, оперативные маршрутные карты, рабочие наряды, планово-учетные
графики изготовления изделий и прочее.
Система ФОБОС предназначена для использования на крупных и средних
машиностроительных предприятиях. ФОБОС осуществляет внутрицеховое
планирование и управление, традиционно принимая и выдавая входные и выходные данные ERP-системе, которая обычно используется в машиностроении
на крупных заводах. Как правило, это тяжелые ERP-продукты, такие как BAAN
и SAP, взаимодействие с которыми осуществляется посредством интеграции,
хотя в настоящее время ведутся работы и по интеграции с «1СПредприятием».
В комплексе с этими системами система ФОБОС способна решать большинство задач крупного предприятия [19].
В модуле оперативно-календарного планирования Omega Production используется эвристический алгоритм формирования плана. Управление качеством плана при использовании эвристических алгоритмов производится через
манипулирование параметрами алгоритма. Примеры таких параметров – загрузка оборудования, приоритет партий, точность определения производственных ресурсов и т.д. Для каждого параметра выделяется перечень возможных
значений. Пример возможных значений для параметра «загрузка оборудования» – равномерная загрузка, максимальный коэффициент загрузки и т.д. [20].
17
Расчет производственной программы производится под заданные критерии оптимальности с использованием данных о приоритетах заказов или партий изделий [21].
Параметрами, на которые может влиять сотрудник плановодиспетчерской службы, являются сроки запуска/выпуска как заказов и изделий,
так и определенных партий; изменение размеров партий (партия может дробиться для более динамичного процесса производства, или, наоборот, несколько партий могут объединяться в одну); изменение режимов работы как конкретного производственного оборудования и персонала, так и производственного подразделения. Одним из способов управления является манипуляция параметрами исходных данных, которые вводятся в систему на основе экспертных данных [20]. В системе не предусмотрена возможность, когда сама система
предлагает значительное улучшение за счет изменения исходных параметров.
В документации на данную систему [21] говорится, что «на основании
производственной программы производится формирование заданий по рабочим
местам с возможностью отслеживания их выполнения. Система позволяет гибко корректировать производственную программу. Существует ручной режим
корректировки и автоматический, который основывается на закрытии нарядов
сменных заданий». На основе данного утверждения можно сделать предположительный вывод, что при возникновении непредвиденных ситуаций система
может перестраивать план производства, а не просто осуществлять мониторинг
за состоянием выполнения заказов.
YSB.Enterprise.Mes возникла в деревообрабатывающей промышленности
и ввиду особенностей, изложенных ниже, ориентируется на сектор средних и
мелких предприятий. Система YSB.Enterprise функционировала на предприятиях среднего размера и постепенно расширила свои функциональные возможности по сравнению с функциональностью типичной MES-системы, включив в
свой состав продажи с формированием портфеля заказов, возможности по
управлению складским дефицитом (не только производственного происхождения) и даже бухгалтерию с расчетом заработной платы различными способами.
Конечно, уровня полноценной ERP-системы функциональность YSB.Enterprise
пока не достигла, тем не менее, имеющихся возможностей может быть достаточно для многих российских предприятий. Такая политика позиционирования
системы выбрана из-за того, что предприятия среднего класса и ниже, уже переросшие уровень возможностей системы «1СПредприятие», пока обделены
полноценной производственной автоматизацией, т.к. цены на западный и российский софт, ориентированный на серьезное производство, не говоря уже об
оптимальном его планировании, пока превышают уровень доступности для
большинства компаний, вынужденных значительную часть средств инвестировать в свое развитие [19].
Расширенный спектр функций YSB.Enterprise по сравнению с традиционными MES предоставляет возможности учета дополнительных данных при
управлении производством. Так, включение склада позволяет организовать определение приоритетов при запуске заказов в производство, к примеру, при не18
достаточной обеспеченности покупными материалами или отсутствии предоплаты за заказ [19].
Система PolyPlan имеет меньший набор функций MES, но позиционируется как система оперативно-календарного планирования для автоматизированных и гибких производств в машиностроении. Российская MES-система
PolyPlan ориентирована на машиностроительные производства, но, кроме традиционного класса обслуживающих устройств типа рабочих центров (РЦ), оперативно-календарное планирование PolyPlan предполагает формирование расписаний для транспортных систем, осуществляющих перевозку партий деталей
между РЦ, для складских устройств приема-выдачи партий деталей и для бригад наладчиков. Ввиду отсутствия явного контура оперативной диспетчеризации PolyPlan стоит несколько дешевле указанных выше систем [19].
Система MES PolyPlan легко адаптируется для управления и неавтоматизированным производством. Ориентированная на машиностроение, она может
быть также использована и на этапе маркетинга, – программа позволяет на укрупненных данных определить возможность выполнения портфеля заказов по
существующим фондам времени технологического оборудования. При оперативном планировании производства возможно получение нескольких допустимых решений расписания. Чем выше глубина поиска, которая задается пользователем, тем больше время счета, но и тем выше точность построения расписания. Точность «однопроходной» оптимизации, часто используемой в таких задачах, отличается от оптимального решения не более чем на 5-7%, но на порядки экономит время счета [19].
В версии 1.8 системы Zenith SPPS реализован полноценный обратный
расчет расписания. В случае такого расчета для каждой рассчитываемой позиции оперативного плана делается попытка установить максимально позднее начало выполнения операций, при котором еще возможно завершение работы в
срок (стратегия Just-In-Time). В результате появляется возможность позднее закупать необходимые для производства материальные средства. В отличие от
имеющейся в версиях 1.5-1.7 функции «Поздний срок запуска», обратный расчет работает точно и поддерживает сборы, но при этом требует гарантированного запаса свободного времени на рабочих местах. Функция уплотнения позволяет корректно убрать из плана неоправданные простои, возникшие вследствие оптимизации расписания по другим критериям. В результате происходит
дополнительная оптимизация плана. При перерасчете расписания можно сохранить изменения периодов выполнения операций, сделанные в ходе диспетчирования предыдущего расписания [22].
В T-FACTORY 6 MES предусмотрены средства сетевого и перспективного планирования на неограниченный период времени. Планирование возможно
осуществлять также во внешних программах – например в MS Project® [23, 24].
Основное отличие T-FACTORY 6 MES от конкурирующих разработок, отмечаемое самим производителем, заключается в следующем [25]:
­ T-FACTORY 6 MES – коробочный продукт, который может быть полностью
освоен и внедрен силами отдела АСУ предприятия;
19
­ T-FACTORY 6 MES основан на технологиях реального времени, разрабатывается в тесной интеграции с системой АСУТП предприятия (как бы «вырастает» из нее).
В целом система представляет достаточно сильные средства для автоматизации производства и смещена в большей степени в направлении ERPсистем.
Система Preactor (Великобритания) формируется на этапе построения логической модели производства. В процессе описания основного технологического оборудования с каждым инвентарным номером связываются какие-либо
ограничения, способные оказать влияние на его доступность или характеристики работы. В качестве вторичных ограничений может выступать предел потребления электроэнергии, необходимость присутствия оператора на определенных рабочих местах, наличие специфической оснастки и т. п. В дальнейшем
при планировании и коррекции плана система будет отслеживать доступность и
объем использования вторичных ограничений. В случае превышения или нехватки ресурсов система, прежде всего, проинформирует об этом диспетчера, а
затем предложит принять либо отклонить условия этого варианта плана [26].
Идеальным решением является комплексная автоматизация, предлагаемая, например, ERP-системой Axapta от Microsoft. Но, в существующих экономических условиях далеко не все предприятия могут позволить себе использование таких систем. Поэтому приходится автоматизировать предприятие несколькими продуктами различных производителей. При этом необходимо учитывать, что планы по автоматизации не должны сковывать планы предприятия
по развитию: всегда нужно обдумывать решения на шаг вперед [27].
Довольно часто приходится слышать о различных ситуациях, в которых
необходимо планировать новый пришедший заказ по какой-либо стратегии.
Самыми популярными стратегиями являются ASAP («As soon as possible» –
«Планирование как можно раньше») и JIT («Just in time» – «Точно в срок»).
Возможность настройки параметров планирования значительно повышает гибкость системы планирования, однако возможность настройки стратегии отсутствует практически во всех рассмотренных системах и, как правило, предоставляет возможность только для задания выбранной стратегии для всего плана
производства, всего потока заказов, что является достаточно жестким условием.
Рассматривая развитие MES систем, можно отметить частое смещение
понимания MES в сторону ERP-систем. Однако в части, касающейся управления производственными процессами, MES-системы отличаются от ERP тем,
что в MES расчет производственных планов строится на основе множества критериев. В системах ERP планирование, как правило, осуществляется по одному
критерию. В MES-системе ФОБОС таких критериев 14 (например, максимальный коэффициент загрузки, минимальное число используемых станков, равномерная загруженность станков, минимальное число переналадок, минимальная
мощность грузопотока и другие). В системе Preactor таких критериев 8. Минимально возможное число критериев, отличающее MES-систему от систем других типов, равно двум. Различные комбинации критериев позволяют рассчиты20
вать десятки вариантов производственного плана, использовать их как средство
моделирования производственных процессов и выбирать наиболее эффективный сценарий выполнения текущего плана [28].
Только MES-системы оперируют так называемыми векторными, интегральными критериями построения планов. При этом диспетчер, составляя
план, может указать, что должно быть достигнуто в конкретном расписании:
уменьшение календарной длительности выполнения всего задания, уменьшение
длительности операций переналадок, высвобождение станков, имеющих небольшую загрузку и т.п. Оперативность составления и пересчета плана является
также прерогативой MES, поскольку пересчет может вестись с дискретой в одну минуту. Это не означает, конечно же, что каждую минуту рабочему будут
выдаваться новые задания, но это означает, что все процессы в цехе контролируются в режиме реального времени, что позволяет заранее предвидеть все
возможные нарушения расписаний и вовремя принимать соответствующие меры [29].
Критерий, который отражает какой-либо один параметр при построении
плана, называется частным, например, минимизация времени переналадок, минимизация транспортных операций и другие. В отличие от частных критериев,
существуют критерии интегрального характера. К ним относятся, например,
минимум суммарного непроизводительного времени, минимум стоимости выполненного плана и другие [30, 31].
С использованием нескольких частных критериях можно создать очень
большое количество комбинаций, которые могут быть пригодны для различных
производственных ситуаций. Например, в MES-системе ФОБОС имеется возможность получения 100 комбинаций векторных критериев. Такое большое количество векторных критериев в системе ФОБОС достигается комбинированием 14 критериев в группы по три критерия. Для таких случаев системный анализ на основе жесткого руководства «разделяй и властвуй» дает более гибкое
решение – «разделяй, синтезируй, властвуй». Это относится к так называемым
векторным критериям планирования. Векторный критерий – это такой интегральный критерий, в который могут входить несколько частных критериев,
иногда противоречивых (чем более противоречат частные критерии друг другу,
тем сложнее отыскать оптимальное решение). В ряде случаев синтез критерия
осуществляется в процессе уточнения производственного задания по планированию с учетом технологии того или иного производства [31].
При оптимизации планов в MES-системах с помощью векторных критериев используются различные методики, но чаще всего – поиск оптимума на
Парето-множествах [32]. Таким образом, за счет использования в MESсистемах векторных критериев повышается управляемость при построении
расписаний, что существенно сказывается на последующем увеличении эффективности использования парка дорогостоящего оборудования. При планировании партиям деталей могут назначаться приоритеты. Так, в MES-системе ФОБОС некоторым заказам присваивается приоритет в очереди заказов, подлежащих планированию. Приоритет назначается в виде числа от 1 до 100, чем боль21
ше значение, тем выше приоритет, а значит, эта партия деталей будет назначаться на изготовление раньше по времени, нежели партии деталей, имеющих
более низкий приоритет [31].
Необходимость поддержки планирования мелкосерийного производства
приводит к необходимости учитывать большое количество различных интересов и ограничений. Почти все системы при составлении плана производства руководствуются большим или меньшим количеством критериев. Но при этом отсутствует индивидуальный подход к планированию каждого заказа – критерии
и их параметры задаются для всех участников производственного плана в целом, однако при мелкосерийном производстве крайне эффективно применять
индивидуальную подстройку критериев и их параметров для каждого участника. Например, один заказ необходимо выполнить точно в срок, так как заказчик
является новым и достаточно перспективным. Выпуск другого изделия можно
немного задержать, так как на складе уже имеется достаточное его количество
и одним из главных критериев является экономичность изготовления.
Среди требований к MES-системам можно выделить такие, как составление производственного плана на некоторый горизонт планирования с предоставлением возможности корректировки производственного плана в процессе
его выполнения. Если первое требование обеспечивается всеми рассмотренными системами, то второе в различных системах может быть реализовано разными способами. В частности, корректировка может быть ручной или автоматической с подразделением на возможность перестройки расписания и сдвиг всех
зависимых задач на более позднее время. Наибольший интерес представляют
системы, которые могут выполнять на одном и том же горизонте планирования
и корректировку выполнения работ, и обработку поступления нового заказа или
другого ранее непредвиденного события. Это может быть обработка очень
важного заказа, который необходимо срочно выполнить при выполнении поставленного плана производства.
Выше был рассмотрен один из аспектов адаптивности системы, связанный с управлением системой за счет задания параметров заказов, станков, рабочих и остальных участников производственного процесса. Другим аспектом
является адаптивность и управление относительно времени. Все системы производства строят производственный план на некоторый горизонт планирования,
затем полученный план отправляют на выполнение. Продолжительность расчета может быть различной, так как исходные данные также могут различаться –
различные технологические процессы, зависимости между операциями, множество критериев и т.п. В результате, при отсутствии резерва времени, когда, например, необходимо выполнить срочный заказ, следует по возможности сократить продолжительность планирования, а при наличии резерва времени система
должна постоянно улучшать производственный план. В этом смысле система
планирования в общем случае может изменить план производства вплоть до его
полной перестройки. Невозможность точно сказать, каким будет план производства, приводит к аналогии с принципами работы довольно популярной системы Канбан [33], когда заранее неясно, как именно будут выполняться заказы,
22
то есть участники производственного процесса знают только то, что необходимо выполнять в данный момент.
Так, в основе организации производства фирмы «Тойота» лежит годовой
план производства и сбыта автомобилей, на базе которого составляются месячные и оперативные планы среднесуточного выпуска на каждом участке. Последние планы основаны на прогнозировании покупательского спроса (период
упреждения – 1 и 3 месяца). Суточные графики производства составляются
только для главного сборочного конвейера. Для цехов и участков, обслуживающих главный конвейер, графики производства не составляются (им устанавливаются лишь ориентировочные месячные объемы производства). В то же
время колебания спроса и рыночной конъюнктуры имеют свои пределы, за границами которых система Канбан начинает давать сбои [34]. Ориентация на
прогнозируемые данные при мелкосерийном производстве или даже единичных
заказах, может привести к достаточно серьезным потерям.
Управление в рассмотренных системах осуществляется на основе параметров заказов и ресурсов, в частности, приоритетов заказов. Изменяя данные
параметры и запуская систему планирования несколько раз, можно получить
несколько соответствующих вариантов производственного плана и затем выбрать наиболее предпочтительный план производства. Однако моделирование
работы системы с различными параметрами может осуществляться и в автоматическом режиме. Фактически человек стремится найти такие варианты производственного плана, в которых небольшое изменение исходных параметров
может привести к значительному улучшению результатов планирования, то
есть, может быть достигнут наиболее выгодный динамический баланс интересов – трейд-оффов. С учетом требования оперативности систем составления
производственных планов, а именно возможности реагировать на входящие события, ручное моделирование редко используется, что также сказывается на
качестве производственного процесса.
Нельзя не отметить тот факт, что возможность программного продукта
подстроиться к специфике выбранного предприятия с помощью добавления зависимостей, описания критериев повышает качество внедрения системы планирования. В этом смысле системы, которые предполагают небольшую доработку
или расширение, выгодно отличаются от коробочных продуктов.
1.1.4 Системы распределения производственных ресурсов как
сложные системы
В настоящее время однозначного, четкого определения сложной системы
нет. Известны различные подходы и предложены различные формальные признаки определения сложной системы. В частности, советский ученый Г.Н. Поворов предлагает следующую классификацию [36]:
­ сложные системы, которые имеют 104-107 элементов;
­ ультрасложные системы, состоящие из 107-1030 элементов;
­ суперсистемы – системы из 1030-10200 элементов.
Однако понятие элемента определяется в зависимости от задачи и цели
23
исследования системы. Следовательно, данное определение сложности является относительным, а не абсолютным.
По определению А. И. Берга, сложной системой называется такая система, которую можно описать не менее чем на двух различных математических
языках (например, с помощью теории дифференциальных уравнений и алгебры
Буля). Кибернетик С. Бир разделяет все кибернетические системы на простые и
сложные в зависимости от способа их описания: детерминированного или теоретико-вероятностного.
В Большой Советской Энциклопедии дается следующее определение
сложной системы. «Сложная система (C. c.) – составной объект, части которого
можно рассматривать как системы, закономерно объединѐнные в единое целое
в соответствии с определенными принципами или связанные между собой заданными отношениями. Понятием С. с. пользуются в системотехнике, системном анализе, исследовании операций и при системном подходе в различных областях науки, техники и народного хозяйства. С. с. можно расчленить (не обязательно единственным образом) на конечное число частей, называемых подсистемами; каждую такую подсистему (высшего уровня) можно, в свою очередь, расчленить на конечное число более мелких подсистем и т. д., вплоть до
получения подсистем первого уровня, т. н. элементов С. с., которые либо объективно не подлежат расчленению на части, либо относительно их дальнейшей
неделимости имеется соответствующая договорѐнность. Подсистема, с одной
стороны, сама является С. с. из нескольких элементов (подсистем низшего
уровня), а с другой стороны – элементом системы старшего уровня.
В каждый момент времени элемент С. с. находится в одном из возможных
состояний; из одного состояния в другое он переходит под действием внешних
и внутренних факторов. Динамика поведения элемента С. с. проявляется в том,
что состояние элемента и его выходные сигналы (воздействия на внешнюю
среду и др. элементы С. с.) в каждый момент времени определяются предыдущими состояниями и входными сигналами (воздействиями со стороны внешней
среды и других элементов С. с.), поступившими как в данный момент времени,
так и ранее. Под внешней средой понимается совокупность объектов, не являющихся элементами данной С. с., взаимодействие с которыми учитывают
при еѐ изучении. Элементы С. с. функционируют не изолированно друг от друга, а во взаимодействии: свойства одного элемента в общем случае зависят от
условий, определяемых поведением других элементов; свойства С. с. в целом
определяются не только свойствами элементов, но и характером взаимодействия между ними (две С. с., состоящие из попарно одинаковых элементов, которые, однако, взаимодействуют между собой различным образом, рассматривают как две различные системы)».
Все популярнее становится следующее определение сложной системы
[37]: «Сложная система состоит из множества взаимодействующих составляющих (подсистем), вследствие чего сложная система приобретает новые свойства, которые отсутствуют на подсистемном уровне и не могут быть сведены к
свойствам подсистемного уровня. Например, свойства атома водорода такие,
24
например, как спектральные характеристики его излучения, есть свойства
сложной системы, которые несводимы к свойствам его составляющих – электрона и протона».
Рассмотрим, как определение сложных систем можно применить для систем распределения производственных ресурсов.
Высокие требования к обеспечению производственных процессов, сложность современного оборудования и технологий, а также возможность их многосторонней настройки, разнообразие правил и критериев планирования являются причиной высокой актуальности новых методов построения подобных автоматизированных систем. Особенно они востребованы на мелкосерийных и
опытных производствах, а также на предприятиях, использующих современные
методики управления, основанные на децентрализации.
Неопределенность спроса и предложения приводит к тому, что предприятие вынуждено заранее тщательно анализировать рынок и только потом выходить на него, выработав какую-либо свою узкую специализацию. Однако за
время исследования может измениться и сам рынок – изменяется расстановка
игроков, появляются новые конкуренты и т.п. Если провести исследование быстро, качество будет низкое, тщательное исследование занимает длительное
время. В результате, предприятию необходимо подтягивать производство под
требования рынка, состояние которого еще не один раз может измениться.
Ориентация предприятия на мелкосерийное производство повышает его устойчивость на рынке, гибко реагируя на его требования.
Как следствие, требования к результирующему плану не только сложны,
но и трудно формализуемы. В то же время большое их количество и сложность
приводит к довольно большой вероятности появления противоречий, которые
также необходимо разрешать.
Казалось бы, для получения «идеального» плана необходимо максимально снизить стоимость выполнения заказов – для этого необходимо выбрать
наиболее дешевые ресурсы, снизить простои оборудования. Если на этапе построения такого плана было все в порядке и «идеальный» план был получен, то
на последующем этапе исполнения может сложиться ранее непредвиденная ситуация, например, рабочий не успел выполнить заказ в срок. В результате, из-за
того, что индивидуальный план рабочего был достаточно плотным, оказались
сорванными сразу несколько доставок важных заказов. В итоге производственная компания потеряла бы будущую прибыль, так как клиент остался бы неудовлетворенным результатами выполнения его заказа. Ввод нового критерия –
надежности плана, приводит к необходимости построения разреженного плана,
что, в свою очередь, снижает получаемую прибыль.
В то же время, степень учета надежности не является жестко задаваемым
параметром. Насколько сильно нужно учитывать надежность, зависит как от
индивидуальных планов ресурсов или заказов, так и от состояния всего плана в
целом. Например, если один рабочий не успевает выполнить заказ в срок, другой рабочий, если он свободен, мог бы заменить первого. Если заказ выполняется в условиях высокой загрузки, планировать выполнение точно так же, как и
25
на другое, более свободное время, не имеет смысла. Кроме того, задержка в выполнении заказа зависит и от самого рабочего. Таким образом, план должен
строиться адаптивно, то есть подстраиваться к внешним условиям и внутреннему состоянию системы. Внешние условия при этом могут быть сложно формализуемыми и носить стохастический характер.
Заказы могут иметь сложную структуру: между планируемыми заказами
могут быть установлены различные отношения, такие как вложенность, предшествование, выполнение в то же самое время.
В такой системе иногда могут появляться различные нелинейные процессы. Примером может служить следующая ситуация. Клиент попросил отменить
свой мелкий заказ с некоторой компенсацией. После того, как в производственном плане образовалось вакантное местно, несколько заказов могут попытаться
его занять. Эти заказы были запланированы на рабочих с более высокими разрядами, а вакантное место соответствует рабочему с более низким разрядом. В
результате, заказы ушли от прежних рабочих. На их место направились остальные заказы, вовлекая все большее количество заказов не только от других рабочих, но и осуществляя подвижки во времени у одного и того же рабочего. Таким образом, при отмене одного небольшого заказа может наблюдаться значительное улучшение плана производства в целом.
Производство даже простых изделий может состоять из множества технологических операций. Каждая технологическая операция обладает набором
индивидуальных требований как к оборудованию, так и к рабочим, выполняющие данные операции.
Кроме жестких индивидуальных ограничений, для каждой сущности в
системе могут задаваться и предпочтения, которые характеризуют состояние не
только как допустимое или недопустимое, а более точно. Предпочтения отдельных сущностей могут противоречить друг другу, что приводит к необходимости взаимодействия данных сущностей – разрешения появляющихся конфликтов. При этом поиск баланса предпочтений различных сущностей или так
называемых трейд-оффов выходит на первый план.
Таким образом, большое количество как самих элементов системы, для
которых осуществляется планирование, так и задаваемых для них индивидуальных предпочтений, а также взаимодействие данных элементов между собой
с целью поиска баланса интересов, приводит к необходимости рассматривать
систему управления распределением производственных ресурсов, в состав которой входит сам производственный план, как сложную систему.
1.1.5 Классификация систем распределения производственных
ресурсов
Существует множество критериев, по которым можно классифицировать
системы распределения производственных ресурсов. Рассмотрим основные из
них.
В зависимости от того, как системы распределения производственных ресурсов взаимодействуют с внешним миром, их можно разделить на следующие
26
типы:
­ закрытые – изолированные системы, у которых отсутствует какой-либо обмен энергией, материей и информацией с окружающей средой. Данный тип
систем практически не встречается, так как выходом систем распределения
производственных ресурсов должен быть план, а входными параметрами –
как минимум параметры новых заказов;
­ открытые – в отличие от закрытых, обмениваются энергией, материей или
информацией с окружающей средой.
Необходимость поддержания конкурентоспособности изделий на соответствующем уровне вынуждает промышленные предприятия к постоянному
обмену с внешней средой, причем не только посредством денежных потоков,
но и за счет получения сырья, заготовок, изготовления сложных модулей, которые затем будут интегрироваться заказчиком в более крупную систему. Отчасти это связано также со значительным повышением сложности изделий и специализации мастерских, цехов и предприятия в целом.
Необходимо отметить, что само построение плана не является целью. Целью является выполнение технологических процессов наилучшим образом. При
этом можно выделить фазу планирования и фазу исполнения полученного плана.
Одним из важных критериев классификации систем распределения производственных ресурсов является наличие обратной связи. Можно выделить
следующие типы:
­ с обратной связью – данные системы могут произвести перепланирование
некоторых заказов, если следующий цех, в который должны перейти изделия из первого цеха, не успевает настроить оборудование, или какой-либо из
необходимых станков сломался. Данные системы характеризуются наличием фазы исполнения запланированных заказов;
­ без обратной связи – результатом работы таких систем является план, который уходит на выполнение и больше не модифицируется.
Распределение производственных ресурсов для планирования различных
изделий требует учета множества факторов: следования технологических операций друг за другом, необходимости выполнять эти операции рабочим и станком одновременно, разнообразия типов станков, а также специализации рабочих. Все это приводит к тому, что возможность коррекции плана производства,
то есть наличие обратной связи, является одной из обязательных задач систем
распределения производственных ресурсов.
Планирование может осуществляться как на ближайшее время, так и на
момент времени, который находится за интервалом исполнения. Таким образом, можно выделить два типа систем:
­ Планирование за горизонт исполнения – все заказы, находящиеся от текущего времени t до некоторого t te , где te – горизонт исполнения, считаются
ушедшими на исполнение и никакой новый заказ не может быть запланирован в этот интервал. Данный подход обычно используется, когда планирование осуществляется на следующий день, а план, полученный днем раньше,
27
выполняется в текущее время.
­ Оперативное планирование – как таковой горизонт исполнения не задается,
так как планирование может осуществляться на ближайшее время. Данный
подход дает возможность подхватывать заказы, которые приходят «в последний момент» и производить перестройку текущего плана.
Во время производства могут происходить различные непредвиденные
ситуация, такие как, например, поломка станка, болезнь рабочего или наоборот
возвращение его на производство, отмена производства изделия, приход срочного заказа. Необходимость гибко реагировать на такие ситуации и приводит к
оперативному планированию. От того, какая последует реакция, в частности,
зависит и стоимость производства.
Планирование может осуществляться двумя способами:
­ батч-планирование – перед планированием заказы группируются в пакет и
только потом отправляются на планирование;
­ заказы вбрасываются в систему по мере их получения.
Появление различных событий, требующих немедленной реакции, таких
как, например, поломка станка, приводит к необходимости обрабатывать события по мере их поступления. Однако в связи с высокой загрузкой система может иметь тенденцию накопления в очереди некоторого пула событий и извлекать оттуда по мере необходимости новые события. Такая функциональность
является развитием вбрасывания заказов по мере их поступления, а не батчпланированием, так как заказы вбрасываются не жестко заданной группой, а
система сама адаптивно выбирает те события, которые необходимо обработать
в первую очередь.
Можно выделить два аспекта разделения типов систем распределения
производственных ресурсов на стохастические и детерминированные:
­ по особенности процесса планирования:
стохастические – логика планирования может меняться от запуска к
запуску системы. Данная ситуация возможна, если логика принятия
решений зависит как минимум от одной случайной величины;
детерминированные – процесс принятия решений жестко определен;
квазидетерминированные – системы, в которых невозможно заранее
точно предсказать развитие процесса принятия решений, однако логическая цепочка построения плана остается постоянной;
­ по результату работы системы:
стохастические – результат работы системы планирования может изменяться от запуска к запуску в связи с тем, что логика принятия решения может зависеть от некоторых случайных величин;
детерминированные – результат работы системы постоянен от запуска к запуску.
Так как при составлении плана производства учитывается большое количество различных требований и ограничений, можно говорить о том, что система распределения производственных ресурсов не может быть детерминированной. Например, логика работы системы в сильно загруженном плане производ28
ства отличается от логики работы в практически пустом плане. Наличие и отсутствие большого количества зависимостей в плане также влияет на процесс
составления плана производства. Если система должна адаптивно реагировать
на такие ситуации, необходимо чтобы система была либо стохастической, либо
квазидетерминированной. Вместе с тем, есть еще один аспект, на который необходимо обратить внимание – это разработка системы. Если разработка системы сложна и занимает значительное время, предполагается длительная фаза
тестирования. Если от запуска к запуску на одних и тех же данных система будет давать различные результаты, поиск ошибок будет значительно затруднен и
время разработки системы в целом будет увеличено. Именно поэтому система
распределения производственных ресурсов в современном производстве должна быть квазидетерминированной по логике планирования и детерминированной при получении результатов работы.
Стохастика является следствием открытости системы распределения ресурсов и присутствует в том смысле, что в систему в неизвестные моменты
времени извне приходят новые события, такие как новый заказ, поломка станка
и другие.
При планировании новых заказов системы распределения ресурсов изменяют план производства. Изменения плана можно разделить на локальные и
глобальные. Под локальными изменениями подразумевается, что при планировании было изменено всего несколько сроков выполнения запланированных заказов. Примером может служить планирование, когда новый заказ размещается
без какого-либо перепланирования уже запланированных заказов. Если перестраивается большая часть производственного плана, изменения называются
глобальными. Предельной ситуацией является изменение всего плана. На основе данных отличий можно выделить следующие типы систем распределения
производственных ресурсов:
­ системы, перестраивающие план целиком;
­ системы, локализующие изменения плана.
Необходимость системы реагировать по-разному на заказы, которые необходимо выполнить срочно, либо через некоторое время, приводит к необходимости гибко реагировать на время принятия решения. Чем больше нужно будет подвинуть запланированных заказов, тем больше потребуется пересогласований и тем больше будет время принятия решений. Вторым фактором является
то, что изменение большого участка плана потребует большого количества согласований с исполнителями данного плана: рабочими, мастерами, начальниками цехов.
При осуществлении планирования возникает ситуация, в которой необходимо сгенерировать несколько путей решения проблемы и выбрать один из
них. Данная операция предполагает оценку всех полученных вариантов. На основе того, в какой степени используется подход к генерации и оценке вариантов, системы распределения производственных ресурсов можно разделить на
два крайних типа:
­ переборные – состоят из двух блоков: блока генерации вариантов и блока их
29
оценки;
­ с использованием направленного поиска – в данном типе систем варианты
не генерируются. Рассматривается один вариант, который постепенно шаг за
шагом улучшается.
Деление систем распределения производственных ресурсов на переборные и с использованием направленного поиска является условным, так как многие системы сочетают два указанных подхода. Поэтому в большинстве случаев
можно говорить лишь о «тяготении» к одному из типов. Полностью переборный принцип для составления плана производства применить невозможно, так
как предполагается слишком большое количество его вариантов. В общем случае задача является NP-полной.
Задача составления плана производства является многокритериальной:
требуется рассматривать множество различных интересов – рабочих, начальника цеха, необходимость окупать оборудование, требования заказчика к определенным срокам и качеству исполнения. На основе того, как используются критерии, среди типов систем можно выделить следующие:
­ по набору критериев:
составление плана по фиксированному набору критериев;
возможность расширять набор критериев;
­ по настройке критериев:
набор критериев для всей системы в целом;
наборы критериев можно задавать индивидуально для каждого участника технологического процесса.
Фиксированный набор критериев полезен для того, чтобы начать работу с
системой, однако иногда очень важно рассмотреть план производства под другим углом зрения, введя дополнительный критерий. От возможности расширять
набор критериев обычно отказываются, что связано с тем, что выбранные критерии используются для всей системы в целом и вследствие этого, дают некоторый суммарный результат. Введение критериев, которые также хорошо характеризуют план производства в целом, затруднено.
Вместе с этим, мелкосерийное производство приводит к необходимости
введения различных критериев индивидуально для каждого заказа. Так, один
заказ необходимо выполнить точно в срок. Второй заказ необходимо выполнить максимально дешево, сроки не так важны, однако не дольше полугода.
Для третьего заказа – произвести изделие в течение месяца (хотя длина технологического процесса 3 дня), но с учетом всех рисков по производству, чтобы
обеспечить гарантированное выполнение заказа к нужному сроку. Более того,
по мере выполнения заказа, критерии могут также меняться – просьба клиента,
изменение приоритетов развития предприятия и т.п.
Наряду с критериями заказов, на производстве присутствуют также и
критерии для ресурсов, например, для оборудования. Например, чем больше
дорогостоящих заказов выполняется на новом станке, тем быстрее он окупается. С другой стороны, чем дольше станок простаивает без заказов, тем больший
убыток он приносит. Необходимость проводить техобслуживание станков и их
30
переналадку приводит к тому, что требуется учитывать и критерии работы
станков. Необходимо также учитывать наличие материалов и рабочих.
Таким образом, в мелкосерийном производстве сталкиваются интересы
различных участников производственного процесса, и возникает необходимость построения динамического баланса их интересов. Именно в мелкосерийном производстве делается акцент на уникальность производства, при этом задание общего набора критериев на все случаи и для всех участников производственного процесса невозможно.
1.2 Обзор алгоритмов распределения производственных ресурсов
Существует множество алгоритмов, на основе которых строятся системы
распределения производственных ресурсов. Как показано ранее, такую систему
можно рассматривать как сложную систему. Рассмотрим наиболее известные из
алгоритмов распределения ресурсов с учетом требований к системам распределения производственных ресурсов как к сложным системам.
1.2.1 Списочные алгоритмы
Среди всех алгоритмов распределения ресурсов можно выделить достаточно простые для реализации алгоритмы, которые позволяют запланировать
заказ на необходимые ресурсы. К такому типу относятся списочные (приоритетные) алгоритмы [38]. Предположим, что несколько заказов ожидают планирования. В этом случае заказы выбираются из общего списка и поочередно отправляются на планирование. При планировании заказы выбирают ресурсы и
время выполнения либо по критерию наиболее раннего исполнения, либо в соответствии с другими критериями. Например, выбор рабочего делается на основе близости его разряда к необходимому, заданному в технологической операции. Заполняя постепенно свободное место операциями, списочный алгоритм
строит производственный план до достижения локального оптимума. Критерии
выбора из списка могут быть различные [39]. Например, задачи выбираются по
принципу очередности прихода в систему (First Come First Served – FCFS). Другим критерием может служить приоритет. Вначале планируются те заказы,
приоритет которых максимален в очереди (Highest Priority First – HPF).
Другой эвристикой для определения порядка планирования заказов может служить планирование, которое начинается с более коротких заказов по
направлению к более длинным с учетом заданных условий (необходимо запланировать максимальное количество заказов или максимально повысить утилизацию ресурсов). Задачи могут планироваться исходя из временных окон, в которые они должны быть выполнены. Так, первыми будут планироваться те заказы, у котороых максимально допустимое время исполнения минимально по
отношению к другим заказам из списка.
Наконец, может учитываться сложность планирования заказа: сложный
заказ, состоящий из множества подзаказов, связанных различными ограничениями, необходимо планировать раньше, так как более простые заказы имеют
большую степень свободы при планировании. Необходимо также упомянуть и
31
метод Монте-Карло, в соответствии с которым заказы выбираются из очереди в
случайном порядке. После планирования осуществляется оценка результирующего производственного плана. Затем заново повторяются фазы планирования
и оценки. Данные операции повторяются до тех пор, пока качество плана не
будет удовлетворительно, либо выполнится необходимое количество итераций,
либо скорость роста качества «лучшего» производственного плана уменьшится
до некоторой величины.
Некоторые из вышеприведенных алгоритмов используются также в системах реального времени при распределении задач по выполняющим их процессорам. Примеры использования данных алгоритмов можно найти в [40].
Списочные алгоритмы обладают рядом недостатков. В частности, алгоритмы подразумевают наличие очереди задач. В случае если очереди нет, алгоритм неприменим. Таким образом, системы, основой которых служат списочные алгоритмы, вынуждены работать только в батч-режимах. Чем больше размер батча, тем эффективнее работают рассматриваемые алгоритмы. Это приводит к тому, что все задачи объединяются в большие батчи и планируются за
пределы горизонта планирования, что приводит, как правило, к глобальным перестройкам плана и низкой эффективности оперативного изменения плана в
случае непредвиденных обстоятельств. Таким образом, данный алгоритм обеспечивает достаточно низкую адаптивность.
1.2.2 Алгоритм имитации отжига
Алгоритм имитации отжига основывается на аналогии с термодинамическим процессом, который происходит при кристаллизации вещества из жидкого
состояния в твѐрдое. Изначально делается допущение, что атомы предварительно выстроились в кристаллическую решѐтку. В то же время часть атомов
может переходить из одной ячейки в другую. Данный переход осуществляется
с некоторой вероятностью. Температура постепенно понижается. Вероятность,
в свою очередь, также уменьшается с понижением температуры. Стабильная
кристаллическая решѐтка соответствует минимуму энергии атомов – «охлажденному состоянию». Изначально метод был предложен в 1982 году и описан в
[41]. В общем виде описание алгоритма можно найти в [42].
Данный подход нашел свое применение в системах распределения ресурсов. Для этого над планом определяются несколько операций, которые приводят к его изменению:
­ размещение заказа на ресурс (для полного размещения заказа, в зависимости
от необходимого числа ресурсов, может потребоваться несколько раз воспользоваться данной операцией);
­ обмен временем выполнения двух заказов;
­ замена ресурса у заказа на другой ресурс.
Случайно выбирается и осуществляется одна из указанных операций. В
зависимости от того, улучшился план или нет, данный шаг принимается сразу
или с некоторой вероятностью P(t) соответственно. Изначально вероятность
P(t) равна 1. С течением времени вероятность снижается, и переход к худшему
32
плану осуществляется все реже и реже. Таким образом, план все сильнее и
сильнее кристаллизуется.
К сожалению, у алгоритма имитации отжига существует следующий недостаток. Вследствие того, что он похож на метод наискорейшего спуска [43,
44], ему свойственно попадать в локальные минимумы и не выбираться оттуда
[45].
1.2.3 Генетические алгоритмы
В настоящее время одними из самых популярных алгоритмов многоэкстремальной оптимизации являются генетические алгоритмы (ГА). Данные алгоритмы основываются на принципах теории эволюции и опыта селекции растений и животных [47]. Идея поиска оптимального решения в генетических алгоритмах заключается в следующей гипотезе: чем выше приспособленность
особи, тем выше вероятность того, что у потомков, полученных с еѐ участием,
признаки, определяющие приспособленность, будут выражены ещѐ сильнее
[48]. Генетические алгоритмы являются подмножеством эвристических алгоритмов поиска.
В n-мерном пространстве задается функция f x1, x2 ,..., xn , которая называется функцией качества, а также приспособляемостью особи. В процессе работы алгоритма выполняется поиск максимума данной функции. Выбираются несколько точек из рассматриваемого n-мерного пространства:
X1 x11, x12 ,..., x1n , X 2 x21 , x22 ,..., x2n , …, X m xm1, xm2 ,..., xmn .
Данные точки называются особями или хромосомами. Координаты самих
точек ( x1 , x2 ,..., xn ) – генами в хромосоме. Выбранные особи составляют начальную популяцию. При работе генетического алгоритма используются две операции, с помощью которых получают популяцию следующей итерации: скрещивание и мутация.
С помощью данных операций из предыдущей популяции появляется новая временная популяция Pn, причем количество особей в полученной популяции больше, чем в исходной. Из полученной популяции удаляются те особи, у
которых значение функции приспособленности наименьшее. Однако решение о
том, какие особи удалять, не является жестко детерминированным. Удаление
происходит с учетом некоторой вероятности, которая зависит от значения самой функции приспособленности. Таким образом, в полученной популяции
окажутся не только особи с наибольшей функцией приспособленности.
Рассмотрим более подробно операцию скрещивания. Данная операция
обеспечивает обмен генетическим материалом. Новый потомок, появляющийся
с помощью указанной операции, может получить лучшие положительные качества своих родителей. В результате значение функции приспособленности для
новой особи будет лучше, чем у исходных родителей. Операция скрещивания
заключается в следующем. Берутся две произвольные особи. Случайно выбирается целое число k, значение которого удовлетворяет неравенству 1 k n . У
обеих особей первые k генов остаются на месте, затем особи обмениваются ме33
жду собой оставшимися частями хромосом. С помощью данного механизма получаются две новые особи. Необходимо отметить, что родители также остаются
в новой популяции. Так как операция скрещивания рождает новые особи обменом группами генов, принципиально новых особей не рождается. В этом случае
алгоритм может легко скатиться в локальный экстремум. Для того чтобы избежать этого, вводится операция мутации.
Операция мутации добавляет в новую популяцию некоторое количество
случайных хромосом. Иногда небольшое изменение лишь одного или нескольких генов в хромосоме приводит к значительному улучшению функции качества для полученной особи.
В системах распределения ресурсов каждому гену ставится в соответствие пара (ресурс, время), которая соответствует состоянию заказа в плане.
Функция приспособленности определяется как количество запланированных
заказов, суммарная утилизация ресурсов или других ключевых показателей эффективности. Может производиться также и минимизация использованных ресурсов. Операция скрещивания, описанная ранее, остается практически без изменений. Операция же мутации изменяет в гене либо ресурс, либо время, либо
и то и другое одновременно.
Особенностью генетического алгоритма является нахождение глобального экстремума в вероятностном смысле. Вероятность нахождения экстремума
зависит от размера популяции. С другой стороны, ни один из операторов не использует знание локального рельефа функции приспособленности. Таким образом, процесс генерации носит стохастический характер, и нет никаких гарантий, что будут сгенерированы особи с более подходящим значением функции
приспособленности. В результате в процессе эволюции получается достаточно
большое количество «неудачных» особей, что, в свою очередь, увеличивает количество обращений к функции качества. Это приводит к увеличению времени
поиска глобального экстремума. Генетические алгоритмы осуществляют поиск
оптимального решения только внутри заданного диапазона. Данная особенность приводит к необходимости задавать как сами диапазоны, так и число
хромосом с большим запасом, что отрицательно сказывается на времени поиска
[49].
1.2.4 Алгоритм поиска критического пути (CPM) и метод оценки и
анализа программ (PERT)
М. Уолкер из фирмы DuPont в 1956 году и Д. Келли из группы планирования капитального строительства фирмы «Ремингтон Рэнд» объединили свои
усилия в области исследования возможности использования ЭВМ для составления планов-графиков крупных комплексов работ по усовершенствованию заводов фирмы DuPont. Результатом их совместной работы стал рациональный
метод описания проекта с использованием ЭВМ. Данный метод изначально был
назван методом Уолкера-Келли. Затем название этого метода было переименовано в метод критического пути (Critical Path Method – CPM) [50, 51]. Данный
метод имеет три достоинства [52] – позволяет получить графическое представ34
ление проекта, определяет ориентировочное время, требуемое для его выполнения, и показывает, какие действия критичны, а какие не столь важны для соблюдения всего графика работ.
Задачи могут иметь сложную структуру: состоять из подзадач, одни из
которых могут выполняться параллельно, а другим необходимо дождаться
окончания выполнения предшествующих задач. Из зависимых задач образуются группы. Данные группы можно представить в виде графа, где вершинами являются задачи, а ребрами – зависимости между задачами. Для графа вводится
специальная терминальная вершина, при достижении которой считается, что
задача выполнена. Как правило, все конечные вершины связаны с данной вершиной.
Для графа вводится понятие критического пути. Существует множество
путей перехода из стартовых вершин к терминальной вершине. Самый длинный из этих путей называется критическим. Именно длиной данного пути ограничено минимальное время выполнения задачи. В случае если план уже сильно
загружен, время выполнения задачи в целом может увеличиться, но никогда не
будет меньше длины критического пути. Увеличение какого-либо другого пути
может и не привести к увеличению длительности выполнения всей задачи.
Таким образом, вначале следует планировать задачи, входящие в критический путь, а затем уже планировать задачи, не входящие в него. Как известно,
задача поиска критического пути в ориентированном графе может быть сведена
к задаче поиска кратчайшего пути, которая, в свою очередь, может быть решена, например, с помощью алгоритма Дейкстры. Данный алгоритм обладает
сложностью O v 2 , где v – число вершин в графе.
Несмотря на то, что целью метода CPM было планирование сложных
проектов, использование метода CPM для планирования проектов с высокой
связанностью внутренних подзадач и высокой неопределенностью сроков выполнения вызывает сложности. Альтернативным методом планирования проектов является метод оценки и анализа программ (Program Evaluation Review
Technique – PERT) [50, 51].
Метод PERT был разработан в 1957г. корпорацией «Локхид» и консалтинговой фирмой «Буз, Ален и Гамильтон». Данный метод предназначался для
управления программой создания ракетной системы «Полярис», состоящей из
60000 операций, выполняемых 3800 основными подрядчиками, которая реализовывалась главным управлением вооружений ВМС США.
Как и метод CPM, PERT основывается на представлении комплекса работ
в виде направленного графа. Отличием метода PERT является возможность
учета вероятностного характера продолжительностей всех или некоторых работ
при расчете параметров времени на сетевой модели. Данный метод позволяет
вычислить вероятности окончания проекта в заданные периоды времени и к заданным срокам. Для этого задаются три оценки длительности выполнения работы:
­ оптимистическая (работа не может быть выполнена быстрее, чем за tiопт ),
35
­ пессимистическая (работа не может быть выполнена дольше, чем за ti пес ),
­ наиболее вероятная ti вер .
Вероятностная сетевая модель преобразуется в детерминированную путем замены трех оценок продолжительностей каждой из работ одной величиной, называемой ожидаемой продолжительностью tie и рассчитываемой как
средневзвешенное арифметическое значение трех экспертных оценок длительностей данной работы:
tie
ti опт
4ti вер ti пес
6
И метод CPM, и метод PERT нацелены на планирование заказов, имеющих сложную структуру. Однако в системе может быть не один такой сложный
заказ. Заказов, которые необходимо запланировать, может быть столько, что
выполнение всех заказов заданными ресурсами невозможно и необходимо эффективно выбрать, какие заказы запланировать, а от каких отказаться. Таким
образом, описанные методы в большей мере ориентированы на выполнение
единичных заказов, а также на фазу выполнения, где возможны отклонения
сроков выполнения подзадач заказов.
1.2.5 Линейное программирование и симплекс метод
Линейное программирование (ЛП) – это метод выбора неотрицательных
значений переменных, минимизирующих/максимизирующих значения линейной целевой функции при заданных ограничениях. В 1939 году Л. В. Канторович опубликовал работу «Математические методы организации и планирования
производства», в которой сформулировал новый класс экстремальных задач с
ограничениями и разработал эффективный метод их решения, таким образом
были заложены основы линейного программирования [54]. Симплекс-метод –
это один из первых специализированных методов оптимизации, нацеленный на
решение задач линейного программирования [55, 56]. В то же время методы
простого и направленного перебора могут быть применены для решения практически любой задачи оптимизации. Симплекс-метод был предложен американцем Г. Данцигом в 1951г. Основная идея рассматриваемого метода состоит в
продвижении по выпуклому многограннику ограничений от вершины к вершине так, что на каждом шаге значение целевой функции улучшается до тех пор,
пока не будет достигнут оптимум. При этом целевая функция и задача ЛП обладают свойством двойственности (т.е. минимум целевой функции может быть
всегда заменен максимумом, путем смены знаков самой целевой функции) [57].
Рассмотрим, как симплекс-метод можно применить к решению задачи
распределения ресурсов. Пусть имеются m видов взаимозаменяемых ресурсов
а1, а2, ., аm, используемых при выполнении n различных работ (задач). Объемы
работ, которые должны быть выполнены, составляют b1, b2, . , bi, bn единиц. Заданы числа ij , указывающие, сколько единиц j-й работы можно получить из
единицы і-го ресурса, а также Cij – затраты на производство j-й работы из единицы i-го ресурса. Требуется распределить ресурсы по видам работ таким обра36
зом, чтобы суммарная эффективность выполненных работ была максимальной
(или суммарные затраты – минимальными). Количество единиц i-го ресурса,
которое выделено на выполнение работ j-го вида, обозначим через xij.
Математическая модель рассматриваемой задачи такова:
n
минимизировать
m
cij xij
j 1 i 1
при ограничениях
m
x
ij ij
b j , где j=1,2,…,n,
i 1
означающих, что план всех работ должен быть выполнен полностью, а
также при ограничениях
n
xij
ai , где i=1,2,…,m,
j 1
означающих, что ресурсы должны быть израсходованы целиком.
С помощью данного метода можно определить, каким образом распределить заказы по ресурсам, в сильно упрощенной форме. При этом не учитывается, что ресурсы могут быть доступны время от времени, а у заказов есть предпочтения, например, крайний срок выполнения, и зависимости в технологических процессах.
Несмотря на то, что симплекс-метод является достаточно эффективным
алгоритмом, показавшим хорошие результаты при решении прикладных задач
ЛП, он является алгоритмом с экспоненциальной сложностью. Причина этого
состоит в комбинаторном характере симплекс-метода, последовательно перебирающего вершины многогранника допустимых решений при поиске оптимального решения [58].
Таким образом, можно сделать вывод, что с помощью симплекс-метода
осуществляется решение задач распределения производственных ресурсов небольшой размерности и со значительными упрощениями. Однако планирование
сложных заказов, выполняемых в мелкосерийном производстве с наличием
множества критериев и различных взаимосвязей, которые могут варьироваться
не только между заказами и ресурсами как классами, но и между самими экземплярами заказов или ресурсов, с помощью симплекс-метода затруднено.
1.2.6 Нейронные сети
Принципы работы нейронных сетей основываются на аналогии с работой
нейронов в нервной системе [59, 60, 61]. Основным элементом нейронной сети
является нейрон. Нейрон состоит из нескольких входов, способных принимать
сигналы, и одного выхода. Принимая сигналы, нейрон взвешивает их и производит суммирование. Затем, согласно определенной для него функции, вычисляет ее значение и передает полученный сигнал далее. В нейронной сети выделяют несколько слоев, каждый слой передает сигналы следующему.
Использование нейронных сетей позволяет производить кластеризацию.
Под кластеризацией понимается разбиение множества входных сигналов на
классы, причем ни количество, ни признаки классов заранее неизвестны. Дан37
ный механизм позволяет объединять похожие заказы и ресурсы в группы, что, в
свою очередь, снижает размерность задачи и способствует повышению эффективности работы системы распределения ресурсов.
Нейронные сети позволяют строить прогнозы о появлении определенных
заказов. Пользуясь данной информацией, можно запланировать заказы более
оптимально по сравнению с тем, как если бы предполагаемые заказы пришли
во время планирования или даже перед своим выполнением. С помощью нейронных сетей также можно определить, какие заказы, на какие именно ресурсы
и на какие моменты времени лучше всего планировать. Однако оценка носит
приблизительный характер и является эффективной только в случае ярко выраженных особенностей. Более того, нейронные сети предполагают предварительную фазу обучения, для осуществления которой необходимы обучающие
наборы данных, в которые входят результирующие планы. Параметры нейронных сетей также определяются неточно. Так, количество нейронов определяется эмпирическим путем, существуют только некоторые рекомендации по выбору размера нейронной сети, подчас противоречащие друг другу.
1.2.7 Мультиагентный подход
Агентом считается все, что действует (слово агент произошло от латинского слова agere – действовать) [53]. Но предполагается, что компьютерные
агенты обладают некоторыми другими атрибутами, которые отличают их от
обычных «программ», такими как способность функционировать под автономным управлением, воспринимать свою среду, существовать в течение продолжительного периода времени, адаптироваться к изменениям и обладать способностью взять на себя достижение целей, поставленных другими. У агента задаются предпочтения, которые соответствуют предпочтениям пользователя.
Агент начинает действовать от лица пользователя. Изначально, а также во многих современных системах, агенты используются для решения различных рутинных задач. В этом случае агенты представляют собой небольшие программы, которым можно назначать задания и указывать различные предпочтения и
ограничения. Некоторые агенты имеет способность про-активно выходить на
пользователя. Например, многие антивирусные программы умеют при обнаружении сомнительных действий, которые могут привести к повреждению или
модификации данных, выйти в диалог к пользователю и предложить варианты
действий, которые необходимо предпринять в сложившейся ситуации.
Идея использования программных агентов оказалась настолько удачной,
что получила свое развитие. Качественный переход произошел в следующем
направлении: агент может не только общаться с пользователем, интересы которого он представляет, но и с другими агентами, которые могут представлять
интересы других пользователей или, в общем случае, произвольных сущностей.
Предпочтения одного агента могут конфликтовать с предпочтениями другого
агента. В этом случае необходимо разрешить конфликт. Для этого агенты с помощью переговоров пытаются выработать компромиссный вариант, который
бы удовлетворил обоих. Например, для заказа, чем меньше стоимость его вы38
полнения, тем лучше. Для выполняющего данный заказ ресурса, напротив,
лучше, когда стоимость выше. Налицо типичный конфликт интересов. На практике данный конфликт решается взаимными уступками по стоимости. В итоге
обе стороны сойдутся на одной стоимости, и конфликт будет исчерпан.
Так появились мультиагентые системы, в которых задаются агент предприятия, агенты заказов, агенты ресурсов. Это первый шаг от централизованного планирования к более распределенному. Распределенное планирование обладает большей гибкостью в том смысле, что планирование осуществляется не
перестройкой всего плана, а локально, изменением только тех частей плана, которые действительно необходимо модифицировать. Данное свойство непосредственно следует из того, что агенты по своей сути изменяют только свой индивидуальный план.
Другим важным свойством, являющимся следствием распределенного
планирования, можно назвать адаптивность. Построение локальных изменений
производится не по жесткому централизованному алгоритму, а является результатом совместной работы отдельных агентов, учитывающих свои состояния и действующих по обстоятельствам.
В [62, 63] приводятся определения агента в «слабом» и «сильном» смыслах. Под интеллектуальным агентом (ИА) в слабом смысле понимается программно или аппаратно реализованная система, которая обладает такими свойствами:
­ автономность – способность ИА функционировать без вмешательства человека и при этом осуществлять самоконтроль над своими действиями и внутренним состоянием;
­ общественное поведение (social ability) – способность функционировать в
сообществе с другими агентами, обмениваясь с ними сообщениями с помощью некоторого общепонятного языка коммуникаций;
­ реактивность (reactivity) – способность воспринимать состояние среды и
своевременно отвечать (реагировать) на те изменения, которые в ней происходят;
­ про-активность (pro-activity) - способность агента брать на себя инициативу,
т.е. способность генерировать цели и действовать рационально для их достижения, а не только реагировать на внешние события.
Сильное определение агента предполагает, что у агента имеется ряд
свойств, дополняющих перечисленные выше. В частности, главным из них является наличие у агента хотя бы некоторого подмножества так называемых
«ментальных» свойств, называемых также интенсиональными понятиями, к которым относятся следующие:
­ знания (knowledge) – это постоянная часть знаний агента о себе, среде и других агентах, т.е. та часть, которая не изменяется в процессе его функционирования;
­ убеждения (beliefs) – знания агента о среде, в частности, о других агентах;
это те знания, которые могут изменяться во времени и становиться неверными, однако агент может не иметь об этом информации и продолжать оста39
ваться в убеждении, что на них можно основывать свои выводы;
­ желания (desires) – это состояния, ситуации, достижение которых по разным
причинам является для агента желательным, однако они могут быть противоречивыми и потому агент не ожидает, что все они будут достигнуты;
­ намерения (intentions) – это то, что агент или обязан сделать в силу своих
обязательств по отношению к другим агентам (ему «это» поручено и он взял
эту задачу на себя), или то, что вытекает из его желаний (т.е. непротиворечивое подмножество желаний, выбранных по тем или иным причинам, совместимых с принятыми на себя обязательствами);
­ цели (goals) – конкретное множество конечных и промежуточных состояний,
достижение которые агент принял в качестве текущей стратегии поведения;
­ обязательства по отношению к другим агентам (commitments) – задачи, которые агент берет на себя по просьбе (поручению) других агентов в рамках
кооперативных целей или целей отдельных агентов в рамках сотрудничества.
Применительно к планированию для каждой задачи и ресурсов, на которые должны быть запланированы задачи, назначаются агенты. И для агентов
задач, и для агентов ресурсов задаются предпочтения. Целью агентов заказов и
ресурсов является построение плана в соответствии с определенными критериями. При запуске мультиагентной системы планирования агенты, основываясь на своих целях и предпочтениях, строят план производства, находя различные компромиссы. Описание различных мультиагентных систем можно найти в
работах [64, 65, 66].
1.2.8 Анализ алгоритмов распределения производственных ресурсов
На основе описанной ранее классификации систем распределения производственных ресурсов, а также методов, с помощью которых осуществляется
планирование, можно выделить следующие критерии, которым должны отвечать алгоритмы распределения производственных ресурсов (Таблица 1).
Таблица 1 – Сравнительный анализ алгоритмов распределения
производственных ресурсов
Критерии
С обратной
связью
Списочные
алгоритмы
–
АлгоГенеритм
тичеимиские
тации
алгоотжига ритмы
–
Постоянная
оценка
генерируемых
особей
CPM и
PERT
Симплекс
метод
Нейронные
сети
–
+
+
Мультиагентный
подход
+
40
Критерии
Оперативное планирование
(приход событий недоступности ресурса, нового
заказа, отмена заказа)
Возможность
планирования не в
батчрежиме
Локальные
изменения
плана
Направленный
поиск
АлгоГенеритм
тичеимиские
тации
алгоотжига ритмы
Практи
Воз–
чески можно,
неосу- однако
щест- требует
вимо
дополнительных согласо
Списочные
алгоритмы
CPM и
PERT
Симплекс
метод
Нейронные
сети
Мультиагентный
подход
+
Простой
пересчет
сроков
выполнения
главной задачи
–
Рекомендации
Тольконе в
батчрежиме
–
+
+
Только СпонГлоЛокаль
не в
танные
баль
ные
батч- измене
ные
режиме ния в
произвольных
участках
плана
Такти- Направ Направ Направ
чески ленный
ленленный
направ- стохас- ность
критиленный тичеобес- ческим
ский
печипутем.
(+)
вается Скорее
отбо–, чем
ром
+
особей
(+/–)
–
Неопределяемо
+
+
–
+
ваний
планов
Малоэффективно
Малоэффективно
–
41
Критерии
Списочные
алгоритмы
Адаптивность к изменениям
предметной области
Сложно
Возможность подхвата изменений в
предметной области в состоянии
уже составленного плана
Детерминированный/ стохастический/ самоорганизация
–
Возможность про-
Полностью
детерминированный
–
АлгоГенеритм
тичеCPM и
имиские
PERT
тации
алгоотжига ритмы
Слож- Очень
Измено
сложно нения
на основе
пересчета
вероятностей.
Достаточно
просто
+
–
+
ДетерЭвоминилюцирован- онный,
ное по- осностроеван
ние с
ный на
неболь итерашим
тив
учетом
ном
стохаст улучше
ики
нии
особей
–
–
Мультиагентный
подход
Легко
Симплекс
метод
Нейронные
сети
–
Легко
–
Переобучение сети
+
Детерминированный
Детерми
нирован
ный
Детер
минированный
+
–
–
Квазидетерминированный,
эволюционнность,
основанная
на итеративном
улучшении
+
42
Критерии
активного
выхода на
пользователя с
предложениями по
улучшению небольших
участков
плана
Направленность
на решение
задач планирования
ресурсов
Поиск глобального
экстремума
Сложность
объектноориентированной
реализации
Списочные
алгоритмы
АлгоГенеритм
тичеимиские
тации
алгоотжига ритмы
CPM и
PERT
+
Ориентация
на широкий
спектр
задач
(+/–)
Ориентация
на широкий
спектр
задач
(+/–)
+
–
–
–
Легко
Средне
Сложно
Симплекс
метод
Нейронные
сети
Мультиагентный
подход
–
+
Используется
для малокритериальных задач
–
–
Ориентация
на построение
связей
заказ/рес
урс
–
Легко
Легко
Норма
льно
Нормально
На основе проведенного анализа существующих алгоритмов можно заключить, что наиболее подходящим для построения системы планирования как
сложной самоорганизующейся системы, удовлетворяющей множеству критериев, предъявляемых современным системам планирования, является мультиагентный подход.
Задача планирования становится важной частью управления сложными
системами. В связи с этим необходимо разработать алгоритмы планирования
ресурсов, базирующиеся на новом подходе к описанию и моделированию
большого числа компонентов сложной системы. Такие алгоритмы базируются
43
на теории сложных систем и, по сути, решают задачу управления распределением задач по времени и ресурсам, что может быть описано как в виде последовательности этапов стратегического планирования, так и в виде параллельного распределения задач. Второй случай соответствует реальной природе задач
планирования в большей мере, однако связан с необходимостью одновременного учета большого количества требований и сложностью формализации поиска
оптимального плана.
В связи с тем, что среда, в которой работает система планирования, подвержена постоянным изменениям, разделение во времени интервала разработки
системы планирования и момента фактического старта работы системы приводит к тому, что система создается по требованиям, заданным гораздо раньше
момента ввода в строй. В итоге, система потенциально будет вынуждена работать совсем в другом режиме. Изменения могут проявляться как на уровне
предметной области, так и в конкретной сложившейся ситуации. Неожиданное
появление различных событий, таких как сложные мелкосерийные заказы, поломки ресурсов, индивидуальные ограничения и предпочтения у различных
сущностей приводит к необходимости строить план адаптивно, основываясь на
свойствах самоорганизации, восходящей к эволюционным принципам.
44
2 МУЛЬТИАГЕНТНАЯ МОДЕЛЬ ПЛАНА ПРОИЗВОДСТВА
2.1 Задачи планирования производства
Среди задач, которые предприятиям необходимо решать при составлении
и выполнении плана производства, можно выделить следующие:
­ поддержка высокой сложности современного производства;
­ необходимость адаптивной обработки событий (новый заказ, новый ресурс
(станок, рабочий и другие), отмена заказа, поломка станка, задержка поставки комплектующих, рабочий на больничном, новый рабочий) в реальном
времени (без полной переделки плана);
­ ориентация на мелкосерийное производство;
­ поддержка постоянных инноваций и изменений в номенклатуре выпускаемой продукции;
­ разнообразие изделий, станков и квалификации рабочих, что необходимо
учитывать в индивидуальном порядке;
­ процесс производства изделия состоит из взаимосвязанных операций, и любое изменение должно учитывать необходимость ситуативной подвижки
всего блока связанных операций;
­ сочетание стадий планирования и исполнения плана;
­ возможность ручной доводки производственных планов;
­ оперативный контроль технологии и планов производства.
Область деятельности промышленного предприятия обычно может быть
связана с производством готовой продукции (ГП) из комплектующих деталей и
материалов (КДМ) по специально разработанным технологическим процессам.
Согласно существующей номенклатуре ГП и КДМ, для каждого типа
продукции обычно известны:
­ общая маршрутная и технологическая карты (Таблица 2, Таблица 3), показывающие последовательность всех операций по изготовлению изделия;
­ описание каждой операции, содержащее сведения о возможных станках,
специальном оборудовании и других средствах технологического оснащения, квалификации рабочих и материальных нормативах для изготовления
данной продукции (операции);
­ описание зависимости между деталями, их количеством и готовыми изделиями.
Кроме этого, имеются следующие данные:
­ конфигурация оборудования цеха и имеющихся станков, находящихся в рабочем состоянии, состоянии монтажа (демонтажа) или ремонта;
­ общий список рабочих и их квалификация;
­ начальный график загрузки всех ресурсов предприятия;
­ информация о затраченных людских ресурсах и заработной плате работникам согласно нормативам (по данным отдела труда и заработной платы
(ОТЗ).
Классическая задача планирования производства состоит в следующем:
45
для каждого цеха необходимо построить свой план производства готовой продукции, для которого требуется обеспечить снабжение цеха комплектующими
деталями и материалами и распределение заданий между работниками с учетом
имеющегося в наличии оборудования.
47
Сверл.
4
25 9–24
Иванов
И.
Петров
И.
гриф
18 8–25
Брак
3
годных
Фрез.
расценка
Принято БТК
дата
15
№ наименование
кол-во
Время
Фамилия
Выдано
в
работу
дата
Норма
Разряд
Операции
Таб. №
Таблица 2 – Пример маршрутной карты детали
43
47
Таблица 3 – Пример технологической карты сборки детали
№
детали
1
2
3
4
5
Наименование операции
Комплектация
Сборка
Маркирование
Испытание
Контроль
Оборудование
Пресс
Краска
Стенд
Количество
1
1
1
1
1
2.2 Мультиагентная модель плана
Рассмотрим подробно мультиагентную модель плана производства
(Рисунок 1). Модель реального мира строится на основе виртуального мира
агентов. Каждому из реальных объектов, среди которых можно выделить станки, рабочих, заказы, присваивается агент. Агенты, согласовывая решения друг с
другом посредством переговоров, строят план производства.
Агенты принимают свои решения на основе базы знаний. Сложная предметная область, состоящая из большого количества различных критериев,
предпочтений и ограничений, оказывает сильное влияние на модель представления знаний. Сложность описания знаний в современных системах планирования является серьезной проблемой. Постоянные дополнения и модификация
порождают требование, чтобы модель была понятна человеку и обеспечивала
гибкую настройку системы по возможности без необходимости доработки и
перекомпиляции исходных кодов системы.
Одним из перспективных направлений в области описания знаний можно
назвать использование онтологий. Использование онтологий обеспечивает гибкость настройки и работы с ней в различных предметных областях [72].
46
Станок 3
Рабочий 1
Станок 1
.
Person 1
Рабочий 2
Станок 2
Person 1
Person 1
Реальный мир
Модель реального мира
Виртуальный мир агентов
Строится на базе
Строится на базе
Базовая онтология Онтология производства
Строится на базе
Модель
производства
Сцена
Рисунок 1 – Модель виртуального мира
В данной работе предлагается разделить базу знаний на следующие элементы:
­ Базовая онтология. Содержит базовые определения: событие, заказ, ресурс,
операция, отношения между операциями, заказами, ресурсами, базовые требования заказа к ресурсу и т.п. Базовая онтология практически не претерпевает изменений и тесно связана с алгоритмами планирования.
­ Онтология производства. Содержит определение изделия, технологического процесса, технологической операции, требования технологической операции к рабочим, станкам, материалам, отношения между операциями в сложных технологических процессах и т.п. Данная онтология расширяет базовую
онтологию понятиями конкретного производства. Перекомпиляция алгоритмов планирования при изменении онтологии производства не требуется, что
и служит основным преимуществом перед базовой онтологией. Необходимо
также отметить, что одна и та же базовая онтология может использоваться в
различных предметных областях, таких как транспортная логистика, цепочка поставок (supply-chain).
­ Модель производства. Содержит описание конкретных изделий, техноло47
гических процессов их изготовления, состоящих из операций, отношения
между ними и т.п. Необходимость использования данной модели представления знаний вызвана ее промежуточным положением между онтологией и
сценой. Онтология производства может быть дополнена концептаминаследниками и их атрибутами, а также отношениями между концептами. В
сцене экземплярам выбранного концепта и отношения задаются различные
значения атрибутов. В этом смысле, модель, с одной стороны содержит описание структуры различных технологических процессов, с другой – описываемые технологические процессы конкретны, например, «Изготовить изделие Болт 728», «Изготовить изделие Скоба». По сути, модель производства
представляет собой набор шаблонов – связанных экземпляров онтологических сущностей. С помощью таких шаблонов можно легко создавать связанные сети элементов в сцене. Модификация модели производства не требует
перекомпиляции алгоритмов планирования.
­ Сцена. Содержит актуальное состояние объектов реального мира, таких как
возникающие события, заказы, ресурсы, план производства и т.п. Так как в
реальном производстве может быть отправлено несколько заказов на изготовление выбранного изделия, в сцене присутствует соответственно несколько создаются в сцене по соответствующему им единому шаблону, описанному в Модели производства. Перекомпиляция алгоритмов планирования при изменении сцены не требуется. Более того, при планировании сцена
претерпевает постоянные изменения вследствие того, что при планировании
как минимум перестраивается план производства.
Рассмотрим более подробно каждый из элементов базы знаний. В базовой
онтологии предметной области содержатся следующие основные классы концептов: заказ, ресурс и событие. С помощью событий реализуется ввод в систему планирования изменений во внешней среде. События также могут генерироваться и самой системой, в этом случае события называются внутренними.
Классы концептов организованы в иерархию на принципах наследования.
Концепт характеризуется свойствами (атрибутами). Концепт Заказ имеет следующие атрибуты:
­ имя,
­ минимальное допустимое время начала,
­ максимальное допустимое время начала,
­ предпочитаемое время начала,
­ длительность задачи,
­ приоритет.
Обычно с именами атрибутов концептов связывают конкретное свойство
объекта. Наследники от базового концепта будут иметь те же самые атрибуты,
те же самые имена свойств, однако алгоритмы, ориентированные только на атрибуты базового класса, будут неспособны учитывать специфику концептов
наследников. Отчасти это вызвано требованием следовать одному из принципов ООП – полиморфизму. Как показала практика, использование отношения
наследования для описания свойств объектов довольно сильно ограничивает
48
возможности применения их в алгоритмах планирования, которые, со своей
стороны, также должны поддерживать простоту расширения предметной области.
Для этого в реализации логики планирования агентов не следует накладывать ограничения на имена ссылочных атрибутов, имена могут быть произвольными, главное условие – уникальность имени. В этом случае поиск атрибутов у концептов при планировании осуществляется не по самим именам атрибутов, а по концептам, на которые они ссылаются, т.е. тип ссылки важнее ее
имени. Например, неважно, какие именно атрибуты ссылаются на заказы, важен сам факт, что есть ссылки на заказы. Таким образом, на основе данного
подхода описание предметной области становится более простым и понятным
применительно к сложной структуре заказов.
Заказы могут быть связаны между собой следующими типами отношений:
­ являться подзадачей. В технических процессах может использоваться произвольное количество отношений «являться подзадачей»;
­ предшествовать задаче. Подзаказы в технических процессах, как правило,
связаны отношениями предшествования;
­ строго предшествовать – никакая третья задача не может быть запланирована на одном ресурсе между двумя данными задачами.
На основе отношения предшествования можно строить также параллельное выполнение заказов (Рисунок 2). Заказ Order 4 имеет два атрибута – ссылки
на предшествующие заказы Order 2 и Order 3, которые могут выполняться параллельно. В свою очередь, каждый из заказов Order 2 и Order 3 имеет атрибут
– ссылку на заказ Order 1, предшествующий им.
Order 2
Order 1
Order 4
Order 3
Рисунок 2 – Использование отношения предшествования для реализации
параллельного выполнения заказов
Для заказов определяется приоритет: чем меньше значение атрибута
«приоритет», тем он выше: заказ, имеющий приоритет 1, более важен, чем заказ
с приоритетом 2.
Для выполнения заказа требуются ресурсы, базовым концептом для которых является Ресурс.
У заказа могут задаваться требования к ресурсам. Требования заказа описываются в базовой онтологии концептом Требования заказа. В онтологии
предметной области можно также определить наследников концепта Требова49
ния заказа.
Требования заказа могут состоять из нескольких элементарных требований к каждому необходимому ресурсу в отдельности. Для этого в наследнике
концепта Требования заказа задается несколько атрибутов, ссылающихся на
конкретные требования. Все разновидности конкретных требований к ресурсу
также имеют общий базовый класс – Требования заказа.
Внутри конкретного требования задается атрибут, являющийся ссылкой
на ресурс. Именно по классу этого атрибута и будет осуществляться поиск ресурса. Кроме указанной ссылки, у концепта может быть задано произвольное
количество пар атрибутов, являющихся предпочтениями заказа к ресурсу: в
первом атрибуте, имеющем такое же имя, как и у атрибута ресурса, указывается
значение, во втором – как именно нужно сравнивать значение первого атрибута
со значением соответствующего атрибута ресурса.
В онтологии определен базовый класс Событие и его подклассы, основными из которых являются:
­ планирование новой задачи,
­ отмена задачи,
­ недоступность ресурса.
Применительно к производству, Онтология производства содержит следующие концепты (ниже приводится только часть используемых концептов):
­ Деталь,
­ Наследники базового концепта Заказ (куда входят как заказы на изготовление, так и элементарные производственные операции):
 технологический процесс, связанный отношениями «Состоит из» с технологическими операциями;
 элементарные технологические операции, связанные с технологическим
процессом посредством отношения «Входит в состав» и отношениями
предшествования с другими технологическими операциями;
­ Наследники базового концепта Ресурс:
 Исполнитель:
Контролер,
Рабочий,
 Оборудование:
Станок револьверный,
Печь шахтенная,
Станок с ЧПУ,
Вертикально-фрезерный станок,
Кругло-шлифовальный станок,
Верстак,
Микрометр,
Ванна гальваническая.
Спецификой онтологии производства является то, что обычно требования
к технологической операции состоят из требований двух видов:
50
­ требование на рабочего (в частности, ограничение по уровню квалификации),
­ требование на оборудование.
Подзаказы, представляющие собой технические операции, из которых состоит сложный заказ, должны выполняться в определенной последовательности
и имеют определенную продолжительность. Описание конкретных технологических процессов делается в Модели производства, например, Изготовить изделие Болт 728, Изготовить зеркало, Изготовить скобу, Изготовить изделие
Струбцина, собрав ее из двух болтов и струбцины. Примером сложного заказа –
технологического процесса, может служить заказ на изготовление изделия Болт
728 (Таблица 4).
Таблица 4 – Описание технологического процесса изготовления изделия Болт
728
Тип
операции
Технологические
операции
Термическая
Охлаждение (отпуск), доотпуск
Револьверная
Торцевать,
Точить,
Отрезать
Длительность (смена)
Разряд работника
Оборудование
2
Токарная
Фрезерная
Шлифовальная
Шлифовка
Сделать
шестигранник
0.5
Проточить,
Нарезать
резьбу,
Отторцевать
1
0.3
0.2
6
3
4
3
4
Печь шахтенная
Станок револьверный
Станок с
ЧПУ
Вертикальнофрезерный
станок
Круглошлифовальный
станок
Таблица 5 (Продолжение)
Тип
операции
Технологические
операции
Сверлиль
ная
Сверлить,
Контровка
Длитель0.2
ность (смена)
Разряд ра- 4
Слесарная
Контроль
БТК
Запилить,
Снять заусенцы
Проверить Покрытие
на соответ- детали
ствие КД
0.1
0.2
0.5
Контроль
БТК,
Окончател
ьная сдача
Внешний
осмотр
Контроль
диаметра
0.1
3
4
6
4
Гальвани
ческая
51
ботника
Оборудование
Сверлильный
Верстак
Микрометр Ванна
гальваническая
Микрометр
В онтологии заказа на изготовление Болта 728 связи концепта-заказа с
концептами-подзаказами показаны синими линиями (Рисунок 3), а связи между
концептами-подзаказами в порядке их выполнения показаны красными линиями.
В модели данных, кроме онтологий и модели производства, можно выделить уровень сцены. Как описано выше, онтология и модель представляют знания о концептах, объектах и их типичных отношениях. Сцена представляет
множество реализаций онтологических классов и моделей, а также их связей,
отражающих конкретную ситуацию, в частности, состояние плана производства. Элементы сцены могут иметь свои уникальные значения атрибутов, в отличие от значений по умолчанию атрибутов соответствующих им концептов и
моделей. Это позволяет при необходимости подстраивать параметры конкретных объектов, не затрагивая настройки для всего класса объектов.
Управление описанной моделью осуществляется посредством внесения
новых знаний в необходимую базу знаний.
Рисунок 3 – Последовательность технических операций при выполнении заказа
на изготовление изделия Болт 728
2.3 Мультиагентный алгоритм планирования
Кратко алгоритм работы мультиагентной системы адаптивного планирования может быть описан следующим образом:
­ Каждый заказ, задача, операция, станок, работник или любой другой ресурс
предприятия получает своего программного агента, у которого ведется свое
расписание;
52
­ Приходящий новый заказ обращается к онтологии (базе знаний, отделенной
от программного кода) и зачитывает оттуда технологический процесс своего
исполнения;
­ Под каждую операцию создается свой агент, который получает требования и
ограничения на планирование;
­ Агент начинает планирование путем поиска необходимых ему ресурсов в
сцене, которая описывает текущую ситуацию в цехе, а именно, какой станок
или рабочий какое расписание исполняет;
­ Если подходящие ресурсы заняты, то фиксируется конфликт, и начинаются
переговоры по его разрешению путем сдвижек и освобождений слотов;
­ В ходе переговоров возможны варианты: новый заказ уйдет на менее подходящий ресурс, предыдущий заказ уйдет или сдвинется;
­ Даже после решения своей задачи каждый агент не останавливается и продолжает пытаться улучшить свое положение.
Опишем логику управления распределением заказов на простом примере
организации производства зеркала заднего вида для автомобиля. Чтобы начать
процесс планирования необходимо ввести событие «Появление нового заказа».
После этого система, постоянно работая, обнаружив поступление нового события, в частности – «Появление нового заказа», для его обработки создает Агента нового заказа, который должен запланировать производство указанного изделия в требуемые сроки. Агент заказа загружает из онтологии описание производственного процесса своего исполнения (Рисунок 4 и Рисунок 5).
Бизнес-процесс изготовления зеркала заднего вида автомобиля
Сделать корпус
Вырезать стекло
Приклеить стекло
Монтировать
к корпусу
зеркало
•Требуется рабочий
•Требуется рабочий
•Требуется рабочий
•Требуется рабочий
квалификации не
ниже 10
•Требуется пресс
•Вход: заготовка
•Выход: корпус
•Время выполнения:
40 минут
квалификации не
ниже 10
•Требуется станок
для резки стекла
•Вход: Стекло
•Выход: Вырезанное
стекло для приклеивания к корпусу
•Время выполнения:
30 минут
квалификации не
ниже 12
•Требуется станок
для
клейки стекла
•Вход: Вырезанное
стекло
для приклеивания к
корпусу
•Выход: Зеркало для
монтирования
•Время выполнения:
20 минут
квалификации не
ниже 8
•Требуется инструмент для
монтажа корпуса
зеркала к
корпусу автомобиля
•Вход: Зеркало для
монтирования
•Выход: Смонтированное зеркало
•Время выполнения:
20 минут
Рисунок 4 – Технологический процесс (ТП) с ограничениями
53
Рисунок 5 – Представление ТП в Онтологии
Далее агент заказа проверяет, есть ли у него подзаказы, выполнение которых необходимо запланировать (Рисунок 6). При наличии таких подзаказов
агент заказа создает агента для каждого из них, устанавливает им цели, стратегии, ограничения и предпочтения, после чего запускает их в работу.
Если текущему заказу предшествует другой заказ, для второго агента
также создается агент заказа. В результате, все предшествующие задачи также
будут запланированы, что отвечает требованию исполнимости расписания.
При планировании подзаказов могут применяться различные стратегии,
основные из них:
­ планирование точно в срок (JIT – Just In Time),
­ планирование как можно раньше (ASAP – As Soon As Possible).
Чтобы запланировать свои подзаказы, главный заказ с помощью сообщения посылает запрос на планирование первому заказу или заказам, которые
возвращает выбранная стратегия. Для стратегии планирования «как можно
раньше» – это самые начальные подзаказы, не имеющие предшественников, а
для стратегии планирования «точно в срок» – самые поздние, которые не являются предшественниками других подзаказов.
54
Агенты технологических операций считывают из онтологии собственные
требования, предъявляемые к станкам и рабочим, и начинают поиск подходящих рабочих и станков для выполнения каждой операции из числа тех, кто свободен или занят, но готов сделать подвижки в своем расписании.
1. Если выбрана стратегия just-in-time, то активи-
Агент заказа по
зируется последний агент в цепочке, все осталь-
производству зеркала
Агент опера-
Агент
ные ждут сообщений и бездействуют.
2. Агент ищет все подходящие по типу станки и рабо-
ции
операции
чих (или берет первые, которые подходят).
«Приклеить
«Монти-
3. Из отобранных рабочих и станков выбираем
стекло к кор-
ровать
самые подходящие по атрибутам (квалификация
зеркало»
рабочего, тип станка).
4. Выбранный рабочий и станок начинают согласо-
заднего вида
Агент
опе-
Агент
опе-
рации
рации
«Сделать
«Вырезать
корпус»
стекло»
«Следует за»
пусу»
«Следует за»
«Следует за»
вывать наилучшее время выполнения работ по их
расписанию. Если в расписании рабочего и станка
есть подходящие слоты времени для выполнения
операции в срок, то на этом планирование операции завершено. Тем самым фиксируется время начала и конца операции.
5. Теперь агенту предшествующей операции в
качестве входного параметра может быть передано требуемое время для завершения его операРаботник Станок
1
2
Станок 1
Работник 3
Станок 3
Работник 2
ции.
6. Остальные агенты действуют по аналогии.
Рисунок 6 – Алгоритм мультиагентного планирования
После того как первые заказы запланировались, их агенты отправляют
запросы на планирование в зависимости от стратегии своим предшественникам/последующим заказам, сообщая о том, на какое время они запланировались. Именно от этого момента времени будут планироваться следующие заказы. После того как запланируется последний подзаказ, агент данного подзаказа
отправляет главному заказу сообщение о том, что все подзадачи запланированы.
При отсутствии каких-либо предпочтений агент заказа может отправить
запрос на планирование сразу всем подзаказам, при этом все подзаказы будут
планироваться параллельно, согласовывая время своего исполнения друг с другом. В этом случае процесс планирования будет адаптивным, т.е. расписание
планируемого производственного процесса будет строиться начиная от наиболее сильно ограниченных подзаказов. Какие именно подзаказы будут сильно
ограниченными, как правило, не известно заранее, т.к. ограниченность подзаказа связана не только с самой структурой техпроцесса, но и с уже сложившимся
расписанием.
В случае возникновения конфликта (например, если расписание станка
уже распланировано: 08:00 – 12:00 ремонт станка, 12:00 – 17:00 производство
55
других изделий) агенты оборудования могут вступить в переговоры для разрешения конфликта: например, производство других изделий переходит на другой станок, который не подошел по техническим характеристикам для планируемой задачи.
Агент заказа по производству зеркала заднего вида
Агент операции
«Сделать корпус»
Агент операции
«Вырезать стекло»
«Следует за»
Агент операции
Агент операции
«Приклеить стекло к
«Монтировать зер-
корпусу»
«Следует за»
«Следует за»
кало»
Найди способ запланировать так, чтобы твоя операция завершилась не
Операция запланиро-
позднее 11:30
вана
с 11:30 до 12:00
Работник Станок
1
2
Станок 1
Работник 3
Станок 3
Работник 2
Рисунок 7 – Схема разрешения конфликта
В результате разрешения конфликта, возможно, потребуется подвижка во
времени других заказов или некоторые из них перейдут на другие станки. В
худшем случае наименее приоритетные заказы будут временно приостановлены, чтобы дать возможность исполнить более приоритетные заказы.
В зависимости от длины технологического процесса, суммарное время
планирования увеличивается (Рисунок 8), но закон изменения близок к квадратическому.
Кроме исследования зависимости изменения параметров производственного плана от длины технологического процесса, интересно также исследование зависимости изменения параметров плана от количества необходимых ресурсов.
Характер зависимости изменения загрузки при планировании заказов, для
которых требуется различное количество ресурсов, остается неизменным, изменяется только сама величина загрузки, так как планирование заказов на
большее число ресурсов приводит к повышению загрузки ресурсов.
Суммарное время планирования заказов (Рисунок 9), в основном, повышается при увеличении количества необходимых ресурсов, но незначительно.
Основной особенностью мультиагентных систем является представление
совокупности агентов в виде виртуального мира, в котором эти агенты существуют, моделируют различные возможные ситуации и решают конфликты путем
переговоров.
56
Например, мир завода может содержать агента заместителя директора и
агентов основных подразделений завода, которые могут вести переговоры на
верхнем уровне, визуализировать план и идентифицировать проблемы верхнего
уровня. Приходящий новый заказ поступает сюда и далее декомпозируется на
основе онтологии на составляющие верхнего уровня, инициируя процессы планирования в каждом из других подразделений. Если некоторые события происходят в цехе и могут быть разрешены путем переговоров внутри цеха, то это не
требует взаимодействия с другими отделами.
Если же не удается решить процесс переговорами локально (например,
из-за задержки, вызванной сбоем оборудования), то план должен попытаться
сначала перепланироваться между подразделениями (по горизонтали). Если и
это не помогает, необходимо информировать заместителя генерального директора и, возможно, выйти на заказчика для согласования сроков поставки изделия или получения дополнительных ресурсов с целью устранения последствий
возникшей непредвиденной чрезвычайной ситуации.
В качестве примера можно привести взаимодействие двух планировщиков в транспортном и производственном цехах:
­ Сценарий 1: Производственный цех задерживается с производством изделия.
Тогда транспорт, который запланирован на перевозку готового изделия клиенту, перепланируется, чтобы не стоять «у ворот» в ожидании готового изделия и не терять деньги.
­ Сценарий 2: Транспорт, который запланирован на перевозку готового изделия клиенту, опаздывает. Тогда цех перепланирует свою работу, и успевает
дополнительно выполнить другой заказ, для которого важно выполниться
как можно скорее.
57
Время планирования 20 заказов в зависимости от длины
технологического процесса
120
100
Время, с
80
60
40
20
0
1
2
3
4
5
6
7
8
9
10
Длина техпроцесса (количество техопераций)
Рисунок 8 – График времени планирования 20 заказов в зависимости от длины
технологического процесса
Время планирования 20 заказов в зависимости от
количества необходимых ресурсов
6
5
Время, с
4
3
2
1
0
1
2
3
4
5
6
7
8
9
10
Необходимо ресурсов
58
Рисунок 9 – График времени планирования 20 заказов в зависимости от
количества необходимых ресурсов
3 АВТОМАТИЗИРОВАННАЯ СИСТЕМА АДАПТИВНОГО
ПЛАНИРОВАНИЯ ПРОИЗВОДСТВА
3.1 Обзор архитектуры мультиагентных систем
В работе [67] рассмотрены классификации агентов, в которой выделены
три основных типа агентов:
­ Реактивные агенты. Термин реактивные агенты впервые возник в работах
Брукса [68]. Реактивные агенты не имеют какой-либо символьной внутренней модели мира и работают по правилам типа ситуация-действие, выбирая
из них действия, наиболее подходящие к конкретной ситуации. Эти агенты
просты по конструкции и сравнительно неплохо приспособлены к работе в
оперативном режиме (режиме, близком к режиму реального времени).
­ Мыслящие агенты (делиберативные). Агенты данного типа обладают внутренним представлением о мире, которое меняется в процессе размышления
агента. Как правило, строится модель размышлений (поведения) агента (например, BDI модель).
­ Смешанные типы агентов. К недостаткам реактивных агентов можно отнести трудность в реализации целеустремлѐнных агентов. Мыслящие агенты,
основанные на общих механизмах рассуждений, являются недостаточно
гибкими и слишком медленно реагируют на внешние события. С целью устранения этой проблемы была введена и описана идея многоуровневой архитектуры агента (агенты смешанного типа). Такая архитектура агента заключается в разбиении функциональности агента на несколько уровней, при
этом каждый уровень работает и взаимодействует с другими на основе иерархии.
Требования к системам планирования производства, ориентированным на
мелкосерийное производство, сформулированные ранее, приводят к необходимости обеспечения такой архитектуры многоуровневых агентов, которая обладает следующими свойствами:
­ Собственное, независимое представление о мире. Позволяет агенту существовать и размышлять независимо от других агентов, взаимодействуя с ними
с помощью сообщений. При этом неважно физическое нахождение агентов –
на одной или разных рабочих станциях.
­ Ориентированность на достижение целей. Позволяет задавать деятельность
и размышления агента с помощью различных моделей, например убеждения
– желания – цели – намерения.
­ Формализованная модель размышлений, направленных на достижение целей. Формализованная модель позволяет не только описывать модели поведения агентов, но и менять их без перепрограммирования системы.
­ Обучение и накопление опыта. Накопление опыта заключается в постоянном
анализе эффективности текущей модели размышлений и изменении модели.
59
Такая возможность позволяет агенту адаптироваться к изменению во внешней среде.
­ Работа в операционном режиме. Агент должен обеспечивать быструю реакцию на входные события и планирование действий в зависимости от оставшегося времени.
­ Построение и применение сложных, многоходовых планов. Для достижения
намеченной цели агенты должны не просто выполнять атомарные или составные действия, а составлять планы выполнения этих действий и корректировать их во время исполнения в зависимости от состояния. Данная возможность позволяет агенту строить несколько независимых планов по изменению своего состояния и согласованного изменения состояния других агентов. Такие планы могут быть конфликтующими или совместимыми. Агент в
своих рассуждениях и реакции на внешние события должен легко оперировать различными планами.
Система, построенная на агентах, удовлетворяющих этим требованиям,
способна осуществлять планирование и принятие решений в распределѐнных
средах, поддерживает гибкую настройку за счет формализации и возможности
изменения целей и моделей поведения агентов, способна к адаптации к изменяющимся условиям, а также поддерживает работу в режиме, близком к режиму реального времени [75]. Отметим, что программная реализация должна поддерживать значительное количество агентов (тысячи) в рамках одной рабочей
станции, для сокращения накладных расходов при межсерверной коммуникации агентов и возможности образования «регионов» – скопления агентов, которые ведут интенсивные переговоры.
В настоящее время существует ряд программных систем, стандарты и
промежуточное программное обеспечение (middleware), которые описывают и
реализуют принципы реактивных агентов, делиберативных и многослойных
архитектур. Рассмотрим представителей каждой из архитектур.
В качестве примера реактивных агентов можно выделить наиболее известное промежуточное программное обеспечение JADE [69]. Эта система позволяет строить агентов на уровне активностей (называемых также ролями или
поведением). Предлагаются сервисы по обмену сообщениями, нахождению
других агентов и сервисов (discovery) и публикации агентами предлагаемых услуг.
Одним из примеров реализации делиберативной архитектуры является
система Jadex [70]. Целью исследовательского проекта Jadex является создание
рационального слоя на базе инфраструктуры JADE, обеспечивающего возможность построения агентов. Jadex реализует модель BDI, расширяя агентов Jade
«убеждениями», «целями» и «намерениями», которые могут быть созданы
внутри агента. Для достижения своих целей агент выполняет планы, являющиеся процедурными средствами, кодированными в Java. В Jadex предусмотрена библиотека планов, которыми может оперировать система. Для пополнения такой библиотеки программист декомпозирует функциональность, которую
должен выполнять агент, в отдельные планы.
60
Наибольший интерес представляет реализация многоуровневых архитектур, т.к. именно они могут являться основой для построения мультиагентных
систем оперативного принятия решений. В качестве примера смешанной архитектуры рассмотрим архитектуру 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 можно отнести требовательную к
аппаратным ресурсам реализацию (что затрудняет использование значительного количества агентов в системе с небольшими ресурсами), а также лимитированное количество слоев в архитектуре агента, которая не предусматривает
расширение. Архитектура не предусматривает специальных средств для обеспечения работы многих агентов на одной рабочей станции в режиме, близком к
режиму реального времени.
3.2 Архитектура автоматизированной системы адаптивного
планирования производства
Система автоматизированного планирования производства реализована
на основе многоуровневой архитектуры агентов.
61
Логическая архитектура описывает интеграцию нескольких планировщиков между собой, а также с существующими АСУ предприятия и промышленными терминалами в цехах (Рисунок 10).
Интеграция планировщиков может производиться с использованием
Enterprise Service Bus (ESB) как по горизонтали, так и по вертикали. Кроме
планировщиков, одной из частей архитектуры является служба анализа деятельности всего предприятия, размещаемая на отдельном сервере, куда производится репликация данных другими серверами подразделений (планировщиками). Данная служба предназначена для мониторинга общей картины по заводу и обеспечивает переговоры агентов всех подразделений.
Интеграция с существующими базами данных и системами может производиться как напрямую с использованием API систем, либо путем прямого обращения к базе данных. Поскольку интеграция планировщиков для разных цехов производится с использованием ESB, в качестве базового варианта предлагается создание адаптеров для ESB, которые позволят преобразовать запросы
оперативных цеховых планировщиков к PDM и ERP системам, а также к АРМ
предприятия (Пример с указанием продукции ГК «АСКОН» см. Рисунок 11).
Рисунок 10 – Интеграция систем
62
САПР 3D
(напр. КОМПАС)
САПР ТП
(напр. ВЕРТИКАЛЬ)
АРМы предприятия
Система Workflow
PDM
(например, ЛОЦМАН:PLM)
ERP
(БД предприятия)
КТД (Данные о
техпроцессах и маршрутах)
Оперативный
планировщик
Оперативный
план
Цеха
Рисунок 11 – Интеграция с АСУ предприятия
Интеграция с промышленным терминалом используется для обеспечения
оперативного доступа к результатам планирования на рабочих местах.
В каждом цехе (на каждом рабочем месте) устанавливается промышленный терминал с сенсорным экраном, через который каждому рабочему показывается его план на день (неделю, месяц) и дается возможность вводить события
(задача выполнена, станок сломан и т.д.). Пример представления информации
на промышленном терминале показан на Рисунок 12.
Представленная архитектура обеспечивает многопользовательский режим
работы в системе, схематично описанный на рисунке (Рисунок 13).
63
Расписание рабочего Иванова И.И.
на 15 мая 2007 года
Время выполнения задачи
Задача
Отметка
о выполнении
08:00 – 09:00
Сделать корпус
Ок
09:00 – 09:30
Вырезать
стекло
Пожалуйста, введите отметку о выполнении по
завершению операции
09:30 – 10:00
Приклеить
стекло к корпусу
10:00 – 11:00
Монтировать
зеркало
Примечание: Если вы предполагаете задержку в исполнении
операции, пожалуйста, введите ожидаемое время завершения
операции – от этого зависит слаженность работы всего нашего
предприятия и его эффективность
Рисунок 12 – Экранное представление плана мастеру в цехе
Мастер
Рабочие
Начальник
цеха
Терминалы
Мастер
Рабочие
Рисунок 13 – Взаимодейсвтие между пользователями системы
64
Описываемая система имеет физическую архитектуру клиент-сервер на
основе технологий Java Enterprise Edition версии 5.0. Для доступа к данным используется технология Enterprise Java Beans 3.0 Persistence и Hibernate, что позволит достаточно просто сменить СУБД в случае необходимости. Рекомендуемые СУБД – MS SQL Server 2000/2005 или Oracle 10g.
Минимальные требовования к техническому обеспечению включают:
­ Локальная сеть TCP/IP, 100 Мб/с;
­ До 10 пользователей на один сервер;
­ СУБД MS SQL Server 2000/2005 или Oracle 10g;
­ Требования к клиентским машинам:
 512 мегабайт RAM;
 CPU Pentium 4, 1.5 GHz;
 ОС Windows 2000/XP;
 Sun Java Runtime Environment 1.5.0;
 Microsoft Excel версии 2000 или выше для просмотра экспортированных
отчетов;
­ Требования к серверам:
 2 гигабайта RAM;
 CPU Pentium 4, 3 GHz;
 ОС Windows 2003 Server;
 Sun Java Runtime Environment 1.5.0;
 JBoss Application Server 4.0.5.
Для запуска приложения и всех его сценариев требуется JDK версии
1.6.04 и выше. Допускается установка Java Runtime Environment (JRE) версии
1.6.04 и выше вместо JDK, но в этом случае выполнить сценарий с изменением
онтологии будет невозможно.
Для установки распакуйте архив с приложением. Полученная директория
должна содержать следующие файлы:
­ папка «data» – содержит необходимые файлы данных, например, файлы базы
данных, настроек приложения;
­ папка «data\scenarios» – содержит данные сценариев испытаний;
­ папка «lib» – содержит библиотеки, необходимые для работы приложения;
­ build.number – номер билда приложения;
­ crimson.jar – jar приложения;
­ Factory.cmd – файл запуска приложения.
Для начала работы с приложением запустите Factory.cmd.
3.3 Интерфейс автоматизированной системы адаптивного
планирования производства
3.3.1 Основной инструментарий
В данном разделе описан интерфейс автоматизированной системы адаптивного планирования производства, представляющий собой интегрированный
65
набор компонентов по редактированию онтологий и сцен, планированию ресурсов и визуальному отображению результатов планирования. Пользователю
доступны следующие команды главного (Рисунок 14).
Рисунок 14 – Главное меню
– CTRL/O – открыть сцену,
– CTRL/S – сохранить сцену,
– сохранить сцену в базу данных,
– обновить,
– SHIFT/F10 – старт (запуск мира агентов),
– приостановить выполнение мира агентов,
– CTRL/F2 – следующий шаг,
– CTRL/I – импортировать расписание из Google Calendar,
– CTRL/G – экспортировать расписание в Google Calendar,
– запустить проактивность.
Меню Файл содержит команды открытия и сохранения существующего
файла, содержащего сцену, экспорта/импорта расписания в Google Calendar
(Рисунок 15).
Рисунок 15 – Меню Файл
Меню Запуск содержит команды запуска и приостановки мира агентов,
перехода к следующему шагу (Рисунок 16).
66
Рисунок 16 – Меню Запуск
Меню Инструменты содержит вызов специальных инструментов, полезных при использовании системы (Рисунок 17). Инструмент Географическая
карта отображает локации (географические точки) и маршруты всех запланированных поездок, если решаются логистические задачи, для решения описываемых задач не используется. Инструмент Радар предназначен для одновременного отображения значений нескольких показателей работы системы
(Рисунок 18). Инструмент Статистика предназначен для отображения статистики работы системы (Рисунок 19).
Рисунок 17 – Меню Инструменты
67
Рисунок 18 – Инструмент Радар
Рисунок 19 – Инструмент Статистика
Инструмент Настройки предназначен для установки значений системных
параметров (Рисунок 20).
Рисунок 20 – Инструмент Настройки
68
Меню Отчеты содержит показатели работы системы по различным позициям (Рисунок 21).
Рисунок 21 – Меню Отчеты
Рабочий экран системы планирования (Рисунок 22) состоит из нескольких областей, содержащих график загрузки оборудования, портлеты, меню, панель инструментов.
Рисунок 22 – Рабочий экран системы планирования
Рабочий экран разделен на несколько секций. Секция в левой части экрана отображает:
­ навигацию по системе (Рисунок 23),
­ события (Рисунок 24),
­ онтологию (Рисунок 25),
­ сцену (Рисунок 26).
69
Рисунок 23 – Окно навигации
Рисунок 24 – Окно событий
Изменения во внешней среде вносятся во внутренний мир системы планирования с помощью событий. События также могут генерироваться и самой
системой, в этом случае события называются внутренними. Окно событий
(Рисунок 24) содержит список, который включает следующие виды событий:
­ новые события,
70
­ события, которые уже запланированы (выполненные события).
Каждое из событий может находиться в следующих состояниях:
­ новое (созданное) – данным состоянием обладают только что созданные события, еще не отправленные на планирование;
­ обрабатываемое – событие находится в процессе/ожидании планирования;
­ обработано успешно – событие удалось успешно обработать, например, для
события планирования задачи, задача успешно разместилась в плане;
­ обработано неуспешно – событие не удалось обработать в силу каких-либо
причин. Например, задача не была запланирована из-за того, что производственный план был довольно плотным, а приоритет планируемой задачи
низким.
Внутри очереди событий могут находиться несколько событий, состояния
которых различны. Для того чтобы отправить события на планирование, необходимо их выбрать и нажать на кнопку Process. После выполнения данного
действия указанные события меняют свой статус на «обрабатываемое». После
смены статуса событий автоматически выполняется запуск мультиагентного
мира с целью обработки указанных событий. Если мир уже был запущен, то
данные события будут обработаны позже, в соответствии с их положением в
очереди.
Кроме событий, слева в виде портлетов представлены онтология и сцена.
Окно онтологий (Рисунок 25) содержит дерево концептов предметной области.
71
Рисунок 25 – Окно онтологии
Окно сцены (Рисунок 26) содержит дерево экземпляров концептов предметной области с указанием количества экземпляров каждого концепта.
72
Рисунок 26 – Окно сцены
По центру рабочего экрана располагается график загрузки оборудования
в виде диаграммы Гантта (Рисунок 27). На нем по горизонтали откладывается
время, по вертикали – ресурсы, загрузка которых интересна пользователю. С
помощью фильтра, расположенного выше, можно выбрать концепт, экземпляры которого или его наследников будут отображены на диаграмме Гантта.
73
Рисунок 27 – Диаграмма Гантта. Расписание запланированных задач для
ресурсов системы
Необходимо отметить, что в элементы фильтра попадают не только ресурсы, но и все концепты, связанные каким-либо отношением с операциями, то
есть имеющие индивидуальный план. В этом случае можно просмотреть индивидуальный план не только ресурсов, но и самих задач, что соответствует более
высокоуровневому планированию.
При выборе какого-либо ресурса на диаграмме Гантта, ниже графического представления отображается в виде таблицы список операций с их атрибутами. В частности, в операции указывается время начала и окончания выполнения задачи, ссылка на саму задачу, признак, является ли она фиксированной.
Вывод о том, какими именно атрибутами обладает операция, определяется на
основе онтологии. Так как производство какого-либо изделия может состоять
из произвольного количества технических операций, иногда возникает необходимость понять, как запланировано изготовление конкретного экземпляра изделия, так как на диаграмме Гантта будут представлены технологические операции по изготовлению остальных экземпляров данного изделия. Для этого
можно включить режим выделения операций по производству всего изделия в
целом.
В некоторых ситуациях возникает необходимость просмотреть, как именно было получено решение. Для этого предназначен лог работы агентов
(Рисунок 28).
74
Рисунок 28 – Лог работы агентов
В данный лог выводятся все переговоры, осуществляемые агентами.
Можно выделить два типа сообщений:
­ сообщения, посылаемые агентами друг другу;
­ сообщения самих агентов о своих действиях и изменении своего состояния.
В связи с тем, что лог работы агентов может быть достаточно большого
размера, необходимы средства его фильтрации. Для этого введены фильтры по
типу сообщения, по отправителю и получателю. Введен также и контекстный
поиск, с помощью которого можно найти любую информацию, выводимую логом работы агентов.
Важной особенностью лога переговоров агентов является сохранение информации о состояниях агентов, отправляющих или получающих сообщение.
Это необходимо для того, чтобы понять, почему тот или иной агент отправил
данное сообщение. Это особенно важно при разрешении различных конфликтов, возникающих между агентами. В отсутствии информации о конфликтах
отладка процесса принятия решений агентами была бы значительно сложнее.
Для работы системы планирования можно указать следующие общесистемные настройки (Рисунок 29):
­ модельное время. Планирование заказов осуществляется на момент времени,
не ранее указанного значения модельного времени. Если модельное время не
задано, используется текущее значение реального времени;
­ время фиксирования – длительность интервала времени, отсчитываемого от
значения модельного времени, в течение которого планирование не осуществляется. Данное время используется для того, чтобы передать и согласовать планы реальных объектов, полученных в системе планирования;
75
­ разность приоритетов для выталкивания. В случае, когда разность приоритетов планируемой и выталкиваемой задач больше указанной величины, выталкивание менее приоритетного заказа признается корректным, иначе будут сгенерированы предложения пользователю о возможных действиях по
планированию исходного заказа.
Рисунок 29 – Общесистемные настройки
3.3.2 Онтология
Онтология мультиагентной системы адаптивного планирования производства может использоваться для описания знаний, используемых агентами
при решении сложных задач динамического планирования производственных
ресурсов. В онтологии описываются основные составляющие плана (ресурсы,
задачи, операции) в виде взаимосвязанных концептов, атрибуты, описывающие
эти концепты и основные взаимозависимости между концептами. Все эти знания используются агентами в процессе переговоров.
Онтология описываемой системы состоит из двух частей:
­ базовая онтология,
­ онтология предметной области.
Базовая онтология содержит следующие концепты (Рисунок 30).
­ Задача (Task),
­ Компонент (Component),
­ Местоположение (Site),
­ Пользователь (User),
­ Ресурс (Resource),
­ Событие (Event),
­ Сообщение (Message),
­ Уведомление (Alert).
Концепты могут быть представлены в виде дерева наследования (Рисунок
30), в виде словаря (Рисунок 31) и в виде семантической сети (Рисунок 32).
Представление в виде семантической сети открывается по двойному клику на
названии концепта в дереве наследования.
76
Рисунок 30 – Дерево концептов онтологии
Рисунок 31 – Словарь концептов онтолоии
Классы концептов организованы в иерархию на принципах наследования.
Концепт характеризуется свойствами (атрибутами).
77
Концепт Задача описывает некоторое мероприятие или производственную операцию. Концепт Задача имеет следующие основные атрибуты:
­ имя,
­ тип стратегии: Just in Time, As Soon As Possible,
­ минимальное допустимое время начала,
­ максимальное допустимое время начала,
­ предпочитаемое время начала,
­ приоритет.
Имена атрибутов не фиксированы, они предназначены только для удобства пользователей. В онтологии используются классы связанных концептов,
причем связь между ними осуществляется по ссылкам, а не по именам отношений между ними. Для задач определяется приоритет: чем меньше значение
приоритета, тем он выше.
Для выполнения задачи требуются ресурсы, каждый из которых описывается концептом Ресурс. Пример представления наследника концепта Ресурс и
его атрибуты показаны на Рисунок 32. Пользователю предоставлена возможность управления уровнем детализации представления концепта в виде семантической сети.
Рисунок 32 – Представление концепта Ресурс в виде семантической сети и
атрибуты концепта Ресурс
Задачи могут иметь требования к ресурсам. Требования задачи описываются в базовой онтологии концептом Требование (Requerements). В онтологии
предметной области можно определять концепты – наследники концепта Требование, уточняющие это понятие в соответствии со спецификой предметной
области.
Для требований определен базовый класс, от которого наследуются все
остальные разновидности требований. В соответствующих наследниках с помощью ссылок могут указываться конкретные требования, у которых также
78
есть базовый класс.
В онтологии определен базовый класс Событие и его подклассы, основными из которых являются:
­ планирование новой задачи,
­ отмена задачи,
­ недоступность ресурса.
Чтобы создать концепт Событие, необходимо выполнить следующую последовательность команд:
­ Навигация → События → Двойной клик (Рисунок 33);
Рисунок 33 – Создание события
­ Создать → Выбрать тип события (Рисунок 34);
Рисунок 34 – Выбор типа события
­ Описать событие выбранного типа, например для событий «Планирование
новой задачи» или «Отмена задачи» необходимо выбрать соответствующую
задачу (Рисунок 35, Рисунок 36), а для события «Недоступность ресурса» –
выбрать соответствующий ресурс и указать начало и конец интервала недоступности (Рисунок 37);
79
Рисунок 35 – Описание события «Планирование новой задачи»
Рисунок 36 – Описание события «Отмена задачи»
Рисунок 37 – Описание события «Недоступность ресурса»
­ Сохранить событие в базу данных.
Концепты Сообщение, Уведомление являются сервисными. Они необходимы для поддержки функциональности системы.
В настоящее время автоматизированная система адаптивного планирования содержит онтологии, описывающие знания о двух предметных областях:
­ онтология планирования мероприятий,
­ онтология производства.
Реализованный алгоритм планирования инвариантен к онтологии, поэтому переключение от одной онтологии к другой не требует переписывания кода
алгоритма планирования.
3.4 Пример типового использования автоматизированной системы
планирования производства
Планирование изготовления изделий рассмотрим на примере планирования изделия Болт 728. Технологический процесс изготовления данного изделия
состоит из десяти технологических операций. Для каждой технологической
операций из этого множества требуется исполнитель (рабочий или контроллер)
необходимой категории и оборудование согласно указанным для данной операции требованиям.
Вначале необходимо создать заказ на изготовление изделия Болт 728. Для
этого в редакторе сцены выбираем концепт Изготовить Болт 728. После этого
по нажатию <Create> создается экземпляр заказа (Рисунок 38). Указывается
предпочитаемое время для планирования производства изделия. Кроме предпочитаемого времени, можно указать стратегию планирования «точно в срок» или
«как можно раньше», приоритет, временные окна, в которые должен быть запланирован технологический процесс.
80
Рисунок 38 – Создание заказа на изготовление изделия Болт 728
После того, как заданы все необходимые параметры заказа, необходимо
создать событие планирования данного заказа (Рисунок 39). Созданное событие
появляется в очереди событий со статусом «новое».
Рисунок 39 – Создание события на планирование изготовления изделия Болт
728
Далее событие необходимо запланировать. Во время планирования событие вначале изменит свой статус на «обрабатываемое», а после этого – на «успешно обработано». В результате распределения ресурсов будет получен план в
81
виде диаграммы Гантта (Рисунок 40).
Рисунок 40 – Производственный план выполнения технологического процесса
по изготовлению изделия Болт 728
Предположим, что станок с числовым программным управлением будет
недоступен первую половину дня 29-го числа по причине, например, его поломки. Для моделирования данной ситуации необходимо создать событие недоступности ресурса (Рисунок 41) и указать в качестве ресурса станок с числовым программным управлением и время – первую половину дня. После создания событие также появляется в очереди событий.
82
Рисунок 41 – Создание события недоступности станка с числовым
программным управлением
После того, как событие недоступности ресурса запланировано, введение
недоступности ресурса на станке с числовым программным управлением приводит к конфликту в плане, так как на это время уже была запланирована технологическая операция. В результате недоступности ресурса технологическая
операция должна сдвинуться. Так как для выполнения технологической операции требовался не только станок, но и рабочий, то операция в плане рабочего
также должна быть сдвинута. Это приводит к возникновению нового конфликта, так как технологические операции связаны отношением предшествования. В
итоге, все технологические операции при разрешении возникающих конфликтов сдвинутся на более позднее время (Рисунок 42).
83
Рисунок 42 – Запланированная недоступность станка с числовым программным
управлением
Перейдем в редактор сцены. В системе планирования было задано два рабочих, обладающих 7-м разрядом. Это означает, что каждый из них мог бы выполнить технологический процесс производства изделия Болт 728, кроме операций контроля, при условии наличия необходимого оборудования.
Предположим, что на производство приняли нового рабочего, разряд которого равен 3 (Рисунок 43).
84
Рисунок 43 – Ввод в систему нового ресурса – рабочего третьего разряда
Раньше, когда этого рабочего не было, высококвалифицированные рабочие выполняли также и простые технические операции, это было корректно, так
как заказ необходимо выполнить, а более подходящих ресурсов не было в наличии. После того, как на производстве появился менее квалифицированный
рабочий, он может выполнить часть технологических операций. Для моделирования данной ситуации добавим нового рабочего в сцену и затем запустим процесс планирования (Рисунок 44). В этом случае во время планирования агент
ресурса проактивно запросит уже запланированные заказы и попытается «переманить» запланированные заказы с других ресурсов. Так, для агентов заказов,
которые могут быть выполнены рабочим не выше третьей категории, более эффективным решением окажется переход на данного рабочего. Что и отражено
на диаграмме Гантта. В рассматриваемом примере изготовления изделия Болт
728 было задано три технологических операции, для выполнения которых необходим рабочий, как минимум, третьей категории
85
Рисунок 44 – Проактивный перехват агентом менее квалифицированного
рабочего набора технологических операций
Кроме одного болта, запланируем также изготовление скобы и еще одного экземпляра болта с целью последующей их сборки в струбцину. Процесс
планирования данных изделий аналогичен рассмотренному выше.
Результат работы системы планирования можно экспортировать в виде
отчетов. В рассматриваемой системе реализован экспорт в электронные таблицы Excel двух типовых отчетов:
­ маршрутная карта (
­
­
­ Таблица 6), в которой указано, кто и когда выполняет технологические операции по производству некоторого изделия;
­ отчет по готовности к сборке изделия (
­
­
­ Таблица 7), в которой указано, когда будут готовы для сборки компоненты,
входящие в сборку. В отчете указываются две даты – планируемая и факти86
ческая. Фактическая дата может отличаться от планируемой, из-за наличия
различных факторов, таких как нехватка количества ресурсов, недоступность рабочих, станков и т.п. В представленной таблице (
­
­
­ Таблица 7) указывается, что для выполнения заказа по сборке струбцины необходимо производство двух болтов и одной скобы. Дата фактического изготовления одного из болтов оказалась больше плановой. Это связано с недоступностью станка, запланированного ранее.
Таблица 6 – Маршрутная карта
Кол-во
6
2
3
0,5
12 Отторцевать
4
1
5 Сделать шестигранник
3
0,3
0 Новый рабочий 15 30.11.2006 12:00 1
6 Шлифовка
4
0,2
0 И. Сидоров
13 30.11.2006 19:12 1
7 Сверлить, Контровка
4
0,2
0 H. Иванов
1 01.12.2006 0:00
1
8 Запилить, Снять заусенцы
3
0,1
0 Новый рабочий 15 01.12.2006 4:48
1
№
Наименование
Дата
Время
Фамилия
Таб. №
Выдано в работу
Расценка
Норма
Разряд
Операции
Охлаждение (отпуск), до13 отпуск
0 И. Сидоров
13 26.11.2006 9:36
1
0 Новый рабочий 15 28.11.2006 9:36
1
Торцевать, Точить, Отре11 зать
Проточить,
Нарезать резьбу,
0 И. Сидоров
13 29.11.2006 12:00 1
87
Проверить на соответствие
9 КД
4
0,2
0 А. Кузнецова
4 01.12.2006 7:12
10 Покрытие детали
6
0,5
0 H. Иванов
1 01.12.2006 12:00 1
4
0,1
0 А. Кузнецова
4 02.12.2006 0:00
1
Внешний осмотр,
14 Контроль диаметра
Таблица 7 – Отчет по готовности к сборке изделия
Изготовить Струбцину
N1
Изготовить скобу
01.12.2006 14:24
02.12.2006 2:24
Изготовить изделие Болт
728
01.12.2006 12:00
02.12.2006 19:12
03.12.2006 0:00
03.12.2006 14:24
88
1
4 ЦЕЛИ, ЗАДАЧИ И СОДЕРЖАНИЕ ЛАБОРАТОРНОГО
ПРАКТИКУМА
Основные цели лабораторного практикума:
­ Изучение основ мультиагентных технологий и возможных приложений.
­ Изучение мультиагентного подхода к решению задач, связанных с динамическим распределением ресурсов в условиях неопределенности спроса и
предложения.
­ Изучение инструментария, используемого для создания мультагентных систем планирования ресурсов в реальном времени.
­ Освоение принципов построения баз знаний (онтологий) открытых мультиагентных систем для различных предметных областей.
­ Приобретение навыков построения мультиагентных систем «распределенного интеллекта», агенты которых способны к переговорам и принятию согласованных решений.
Основные задачи лабораторного практикума:
­ Изучение базовых понятий, определяющих особенности мультиагентного
подхода к проектированию программного обеспечения.
­ Изучение принципов построения мультиагентных систем, предназначенных
для изучения динамики функционирования сложноорганизованных систем.
­ Освоение онтологического подхода к описанию знаний о структуре и алгоритмах функционирования сложноорганизованных систем.
­ Практическое освоение инструментальных средств разработки мультиагентных приложений, связанных с планированием последовательности событий.
­ Освоение методов проектирования и моделирования онтологической сцены
для сложных задач планирования индивидуального или группового расписаний.
­ Освоение приемов использования агентов для адаптивного планирования
событий.
­ Изучение сценариев, реализующих различные алгоритмы планирования событий.
­ Практическое освоение технологии моделирования процессов взаимодействия между объектами в среде открытой мультиагентной исполняющей системы:
 работа с онтологией, включая обновление онтологии «на лету»,
возможность добавления бизнес-процессов ходе моделирования;
 выполнение потоковых вычислений, т.е. расчетов необходимых параметров «на лету», непосредственно в процессе моделирования,
 выполнение матчинга (предварительного выбора возможных вариантов решений);
 принятие решений на основе возможных вариантов;
 пересмотр решений в ходе работы.
В процессе выполнения лабораторного практикума предлагается изучить
возможности применения мультиагентных технологий для решения задач пла89
нирования производственных ресурсов в реальном масштабе времени.
При этом сначала предлагается освоить базовые принципы построения
онтологий и использования мультиагентных алгоритмов планирования на сравнительно простом примере динамического планирования мероприятий на производственном предприятии.
Затем предлагается рассмотреть аспекты применения мультиагентных
приложения для решения более сложных задач: динамического планирования
сборочного производства (на примере зеркала легкового автомобиля) и механического производства (на примере изделия «Болт»). Здесь основное внимание
следует обратить на то, каким образом особенности производства, рассматриваемого как сложноорганизованная система, описываются в онтологии и определяют логику принятия решений в ходе мультиагентных переговоров.
Отметим, что приведенные примеры динамического планирования достаточно широко распространены на любых производствах. При создании этих
примеров учитывались требования современных предприятий, в частности автомобильного и аэрокосмического машиностроения.
Лабораторный практикум посвящен изучению различных аспектов применения мультиагентного подхода для составления расписаний в указанных
выше предметных областях:
1. Построение плана согласованных мероприятий и использования оборудования на производственном предприятии.
2. Планирование технологического процесса производства на основе знаний, представленных в онтологии.
3. Изучение виртуального рынка в задачах адаптивного планирования технологического процесса производства.
4. Изучение логики принятия решений с использованием различных стратегий планирования.
90
5 ЛАБОРАТОРНАЯ РАБОТА №1. ПОСТРОЕНИЕ ПЛАНА
СОГЛАСОВАННЫХ МЕРОПРИЯТИЙ И ИСПОЛЬЗОВАНИЯ
ОБОРУДОВАНИЯ НА ПРОИЗВОДСТВЕННОМ ПРЕДПРИЯТИИ
5.1 Цели и задачи лабораторной работы
В открытых системах, состояние которых изменяется «на лету», особое
значение приобретает возможность реализовать динамическое формирование
расписания выполнения работ, а также адаптивное планирование и перепланирование событий при изменении состояния заказов и ресурсов. Рассмотрим базовые принципы планирования, реализованные в автоматизированной системе
адаптивного планирования, на примере достаточно простой онтологии планирования мероприятий, которая может применяться в самом широком спектре
предметных областей.
Цель лабораторной работы № 1 – продемонстрировать возможности
мультиагентной автоматизированной системы адаптивного планирования для
реализации различных алгоритмов планирования мероприятий в зависимости
от текущей ситуации.
В процессе выполнения лабораторной работы № 1 решаются следующие
задачи:
­ Изучение онтологии планирования мероприятий;
­ Освоение инструментов, предоставляемых для конструирования сцен, планирования последовательности событий и визуализации динамики формирования расписания мероприятий;
­ Изучение основных средств представления плана (представление заказов в
виде цепочки событий);
­ Освоение приемов автоматического и ручного планирования событий;
­ Изучение сценариев, реализующих различные алгоритмы планирования мероприятий.
5.2 Онтология планирования мероприятий
Онтология планирования мероприятий содержит концепты, являющиеся
наследниками концептов базовой онтологии.
Наследники концепта Задача базовой онтологии – Составная Задача
(Complex Task) показаны на Рисунок 45. Иерархия классов в виде дерева концептов представлена в левом окне, а в виде семантической сети – в среднем окне.
91
Рисунок 45 – Концепт Составная Задача и его наследники
Наследники концепта Ресурс базовой онтологии показаны на Рисунок 46.
Рисунок 46 – Концепт Ресурс и его наследники
Выберем задачу «Встреча с секретарем» (Secretary and Participant Meeting) и рассмотрим, как специализируется для данной задачи концепт Требование базовой онтологии. В онтологии предметной области определяется концепт
Требования задачи «Встреча с секретарем» (Requirements for Secretary and Particioant Meeting).
Задаче «Встреча с секретарем» требуются следующие ресурсы:
92
­ комната,
­ секретарь,
­ участники.
Соответственно, к каждому из этих ресурсов могут быть предъявлены
требования. С этой целью определяются соответствующие концепты – наследники концепта Требования задачи «Встреча с секретарем» (Рисунок 47).
Рисунок 47 – Концепты, определяющие требования к ресурсам, используемым
задачей Secretary and Participant Meeting
Каждый из концептов, определяющих требования к ресурсам, имеет свой
набор атрибутов. Например, концепт Требования к секретарю (Requirement –
Secretary for Meeting) у задачи «Встреча с секретарем» имеет атрибуты
­ категория,
­ знание английского языка.
На (Рисунок 48) показано, что в онтологии планирования мероприятий
заданы в виде значений атрибутов следующие требования к секретарю для выполнения задачи «Встреча с секретарем»:
­ категория более 4,
­ знание английского языка.
Рисунок 48 – Значения атрибутов, определяющих требования к ресурсу
Secretary for Meeting
93
5.3 Сценарий распределения ресурсов со свободным расписанием
5.3.1 Описание сценария
Сценарий «iteration_1/01_OpenSlotAllocation.script» демонстрирует работу
алгоритма распределения ресурсов со свободным расписанием («Open slot
allocation»). Требуется запланировать ряд задач при наличии всех требуемых
ресурсов со свободным расписанием. Временных конфликтов между задачами
нет.
5.3.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии планирования мероприятий, присутствующие в сцене, указаны ниже (Таблица 8).
Таблица 8- Экземпляры концептов онтологии планирования мероприятий
Концепты онтологии
Ресурс
Задача
Экземпляры концептов
Участники:
­ John
­ Bill
Помещение:
­ room N123
Проектор:
­ projector1
Встреча:
­ Start-Up meeting1
­ Start-Up meeting2
­ Start-Up meeting3
­ Start-Up meeting4
Значения атрибутов экземпляров концептов приведены ниже (Таблица 9 и
Рисунок 49).
Таблица 9 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«Start-Up meeting1»
­
­
­
Задача
«Start-Up meeting2»
­
­
­
Задача
­
Значение атрибутов
Предпочитаемое время (Preferred Time) –
10:00;
Длительность (Duration) – 2 часа;
Необходимые ресурсы (Required Resources):
John, Bill, projector1 и room №123
Предпочитаемое время (Preferred Time) –
12:00;
Длительность (Duration) – 2 часа;
Необходимые ресурсы (Required Resources):
John, Bill, projector1 и room №123
Предпочитаемое время (Preferred Time) –
94
Экземпляр концепта
«Start-Up meeting3»
Значение атрибутов
­
­
Задача
«Start-Up meeting4»
­
­
­
15:00;
Длительность (Duration) – 2 часа;
Необходимые ресурсы (Required Resources):
John, Bill, projector1 и room №123
Предпочитаемое время (Preferred Time) –
17:00;
Длительность (Duration) – 2 часа;
Необходимые ресурсы (Required Resources):
John, Bill, projector1 и room №123
Рисунок 49 – Значения атрибутов задачи «Start-Up meeting1»
5.3.3 Этапы проведения эксперимента
Действия
Запустите
систему.
На
панели
ментов щелкните кнопку <Open>
(Рисунок 50). Загрузите сценарий
«01_OpenSlotAllocation.script» из папки data/scenarios/iteration_1/.
Запланируйте
задачу
«Start-Up
Meeting1»: на странице «События»
выберите событие для «Start-Up
ing1», затем щелкните кнопку <Действия> и выберите пункт «Запустить
планирование события» (Рисунок 51).
Таким же образом запланируйте
остальные задачи: «Start-Up Meeting2»,
«Start-Up Meeting3», «Start-Up Meeting4».
Отобразите расписание для всех ресурсов (Рисунок 52). Отрегулируйте
Ожидаемый результат
Начальное расписание не должно содержать никаких операций для всех
ресурсов и задач. Задачи и соответствующие события должны быть загружены.
Появившиеся задачи должны быть запланированы в предпочитаемое время
и не должны иметь временных конфликтов. Все ресурсы должны присутствовать на встречах в то же время.
Расписание ресурсов John, Bill, projector и room №123 должно включать
95
Действия
Ожидаемый результат
оптимальный размер изображения при операции «Start-Up Meeting1» в 10:00,
помощи кнопок <+> и <→.
«Start-Up Meeting2» в 12:00, «Start-Up
Meeting3» в 15:00, «Start-Up Meeting4»
в 17:00.
Нажмите здесь
Рисунок 50 – Загрузка сценария
Нажмите здесь
Рисунок 51 – Планирование событий
96
Рисунок 52 – Расписание использования ресурсов
5.4 Сценарий распределения ресурсов с интервалом недоступности
ресурса
5.4.1 Описание сценария
Сценарий «iteration_1/02_ResourceUnavailability.script» демонстрирует
планирование события недоступности ресурса («Resource unavailability»).
Данный сценарий моделирует ситуацию, когда один из ресурсов, участвующих в выполнении запланированных задач, на некоторое время становится
недоступен (например, из-за технической неисправности). В таком случае все
задачи, требующие данный ресурс, должны быть сдвинуты до момента, когда
данный ресурс будет доступен.
5.4.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии планирования мероприятий, присутствующие в сцене, указаны ниже (
Таблица 10).
97
Таблица 10 – Экземпляры концептов онтологии планирования мероприятий
Концепты онтологии
Ресурс
Задача
Экземпляры концептов
Участники:
­ John
­ Bill
Помещение:
­ room N123
Проектор:
­ projector1
Встреча:
­ Start-Up meeting
Уборка:
­ Cleaning
Значения атрибутов экземпляров концептов приведены ниже (Таблица
11).
Таблица 11 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«Start-Up meeting»
­
­
­
Задача
«Cleaning»
­
­
­
Значение атрибутов
Предпочитаемое время (Preferred Time) –
15:00;
Длительность (Duration) – 2 часа;
Необходимые ресурсы (Required Resources): John, Bill, projector1, room №123,
Secretary
Предпочитаемое время (Preferred Time) –
14:00;
Длительность (Duration) – 1 час;
Необходимые ресурсы (Required Resources): room №123
5.4.3 Этапы проведения эксперимента
Действия
Загрузите сценарий «02_ ResourceUnavailability.script»
из
папки data/scenarios/iteration_1/.
Запланируйте задачу «Start-Up
Meeting».
Запланируйте
задачу
Ожидаемый результат
Начальное расписание не должно содержать
никаких операций для всех ресурсов и задач.
Задачи и соответствующие события должны
быть загружены.
Появившаяся задача должна быть запланирована на 15:00 и не должна иметь временных
конфликтов. Ресурсы должны присутствовать
на встрече в 15:00.
Появившаяся задача должна быть запланиро98
Действия
«Cleaning».
Ожидаемый результат
вана на 14:00 и не должна иметь временных
конфликтов. Ресурсы должны присутствовать
на встрече в 14:00.
Расписание для room №123 должно включать
Отобразите расписание для реоперации «Cleaning» в 14:00 и «Start-Up
сурса room №123.
Meeting» в 15:00 (Рисунок 53).
Запланируйте
событие
«Resource unavailability» («Win- Ранее запланированные операции должны
dow repair») для room №123 с сдвинуться. Расписание для room №123
6:00 до 16:00 (
должно включать операции «Cleaning» в
16:00 и «Start-Up Meeting» в 17:00. Другие ресурсы должны содержать операцию «Start-Up
Meeting» в 17:00 в своем расписании.
Рисунок 54).
Расписание для John, Bill, projector, room
№123 и Secretary должно включать операцию
Отобразите расписание для «Start-Up Meeting» в 17:00. Расписание для
всех ресурсов, имеющихся в room №123 должно включать операцию «Reсистеме.
sources unavailability», операции «Cleaning» в
16:00 и «Start-Up Meeting» в 17:00 (Рисунок
55).
Рисунок 53 – События Start-Up Meeting и Cleaning запланированы
99
Рисунок 54 – Планирование события недоступности ресурса room 123
Рисунок 55 – Событие «Resource unavailability» для room 123 запланировано
5.4.4 Индивидуальные задания
1. Дополнительно запланируйте событие недоступности какого-либо ресурса. Наблюдайте, как изменится расписание ресурсов, опишите полученные
результаты.
5.5 Сценарий планирования со сдвигом длинной цепочки операций
5.5.1 Описание сценария
Сценарий «iteration_1/03_WaveThroghResource.script» демонстрирует
планирование задачи со сдвигом цепочки ранее запланированных операций
(«Resource unavailability»).
Данный сценарий демонстрирует успешное планирование задачи в том
случае, когда ее предпочитаемое время пересекает предпочитаемое время задач, уже присутствующих в расписании. Планируемая задача должна быть размещена между двумя уже запланированными задачами путем сдвига времени
их выполнения. В свою очередь, сдвиг времени выполнения двух задач может
вызвать сдвиг времени во всем расписании.
5.5.2 Начальное состояние сцены
Начальное расписание содержит последовательность запланированных
задач: «task1-1», «task1-2», «task1-3», «task1-5», «task1-6», «task1-7», «task2-1»,
«task2-2», «task2-3», «task3-1», «task3-2», «task3-3».
Задача «task1-4-new» должна быть размещена между двумя запланиро100
ванными задачами («task1-3» и «task1-5»), но ее время частично совпадает со
временем выполнения уже запланированных задач.
Для успешного планирования, должен быть применен сдвиг времени
(time shift). Данный сценарий демонстрирует волнообразный алгоритм решения
задачи сдвига времени (waves-like issues solving), который заключается в том,
что время начала операций сдвигается последовательно, т.е., одна операция за
другой.
Экземпляры концептов онтологии планирования мероприятий, присутствующие в сцене, указаны ниже (Таблица 12).
Таблица 12 – Экземпляры концептов онтологии планирования мероприятий
Концепты онтологии
Ресурс
Экземпляры концептов
Участники:
­ John
­ Bill
­ Bob
­ task1-1
­ task1-2
­ task1-3
­ task1-4-new
­ task1-5
­ task1-6
­ task1-7
­ task2-1
­ task2-2
­ task2-3
­ task3-1
­ task3-2
­ task3-3
Задача
Значения атрибутов экземпляров концептов приведены ниже (Таблица 13).
Таблица 13 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«task2-1»
Задача
«task2-2»
Задача
«task2-3»
Задача
­
­
­
­
­
­
­
­
­
­
Значение атрибутов
Предпочитаемое время (Preferred Time) – 09:00;
Длительность (Duration) – 1 час;
Необходимые ресурсы (Required Resources): Bill
Предпочитаемое время (Preferred Time) – 10:00;
Длительность (Duration) – 1 час;
Необходимые ресурсы (Required Resources): Bill
Предпочитаемое время (Preferred Time) – 11:00;
Длительность (Duration) – 1 час;
Необходимые ресурсы (Required Resources): Bill
Предпочитаемое время (Preferred Time) – 12:00;
101
Экземпляр концепта
«task1-1»
Задача
«task1-2»
Задача
«task1-3»
Задача
«task1-4-new»
Задача
«task1-5»
Задача
«task1-6»
Задача
«task1-7»
Задача
«task3-1»
Задача
«task3-2»
Задача
«task3-3»
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
Значение атрибутов
Длительность (Duration) – 1 час;
Необходимые ресурсы (Required Resources): Bill,
John
Предпочитаемое время (Preferred Time) – 13:00;
Длительность (Duration) – 1 час;
Необходимые ресурсы (Required Resources): John
Предпочитаемое время (Preferred Time) – 14:00;
Длительность (Duration) – 1 час;
Необходимые ресурсы (Required Resources): John
Предпочитаемое время (Preferred Time) – 14:30;
Длительность (Duration) – 1 час;
Необходимые ресурсы (Required Resources): John
Предпочитаемое время (Preferred Time) – 15:00;
Длительность (Duration) – 1 час;
Необходимые ресурсы (Required Resources): John
Предпочитаемое время (Preferred Time) – 16:00;
Длительность (Duration) – 1 час;
Необходимые ресурсы (Required Resources): John
Предпочитаемое время (Preferred Time) – 17:00;
Длительность (Duration) – 1 час;
Необходимые ресурсы (Required Resources): Bob,
John
Предпочитаемое время (Preferred Time) – 18:00;
Длительность (Duration) – 1 час;
Необходимые ресурсы (Required Resources): Bob
Предпочитаемое время (Preferred Time) – 19:00;
Длительность (Duration) – 1 час;
Необходимые ресурсы (Required Resources): Bob
Предпочитаемое время (Preferred Time) – 20:00;
Длительность (Duration) – 1 час;
Необходимые ресурсы (Required Resources): Bob
5.5.3 Этапы проведения эксперимента
Действия
Загрузите
сценарий
«03_WaveThroughResource.script»
из папки data/scenarios/iteration_1.
Отобразите расписание для всех
ресурсов, имеющихся в системе.
Запланируйте задачу «task1-4new».
Ожидаемый результат
Начальное расписание содержит последовательность запланированных операций
для трех ресурсов (Рисунок 56).
В предпочитаемое время выполнения задачи task1-4-new -14:30 – John занят. Поэтому
102
выполнение данной задачи может начаться
только в 15:00. На это время уже запланирована задача task1-5. Планирование задачи
task1-4 на 15:00 приведет к сдвигу всех ранее запланированных задач для John: task15 – на 16:00, task1-6 – на 17:00, task1-7 – на
18:00. Так как в выполнении задачи task1-7
участвует Bob, все запланированные для
него задачи также сдвигаются по времени:
task3-1- на 19:00, task3-2 – на 20:00, task3-3
– на 21:00.
Отобразите расписание для всех Расписание для John должно включать опересурсов в системе.
рацию «task1-4-new» (Рисунок 57).
Рисунок 56 – Начальное расписание
103
Рисунок 57 – Конечное расписание
5.5.4 Индивидуальные задания
1. Дополнительно запланируйте задачу «task1-8-new» на 16:45. Для выполнения задачи необходимы Bill и Bob. Наблюдайте, как изменится расписание ресурсов, опишите полученные результаты.
5.6 Сценарий планирования задач с предшественниками
5.6.1 Описание сценария
Сценарий «iteration_1/04_PlanTasksWithPredecessor.script» демонстрирует
поведение системы в ситуации, когда необходимо запланировать задачу, связанную с другой задачей отношением предшествования («Predecessor relation»).
Другими словами, выполнение задачи может начаться только после того, как
будет выполнена предшествующая задача в расписании.
5.6.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии планирования мероприятий, присутствующие в сцене, указаны ниже (Таблица 14).
Таблица 14 – Экземпляры концептов онтологии планирования мероприятий
Концепты онтологии
Ресурс
Экземпляры концептов
Участники:
­ John
­ Bill
Помещение:
­ room N123
Проектор:
­ projector1
104
Концепты онтологии
Задача
Экземпляры концептов
Встреча:
­ Start-Up meeting
Уборка:
­ Cleaning
Значения атрибутов экземпляров концептов приведены ниже (Таблица 15).
Таблица 15 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«Start-Up meeting»
­
­
­
Задача
«Cleaning»
­
­
­
Значение атрибутов
Предпочитаемое время (Preferred Time) –
15:00;
Длительность (Duration) – 2 часа;
Необходимые ресурсы (Required Resources): John, Bill, projector1, room N123
Предпочитаемое время (Preferred Time) –
14:00;
Длительность (Duration) – 1 час;
Необходимые ресурсы (Required Resources): room N123
5.6.3 Этапы проведения эксперимента
Действия
Запустите систему. Загрузите сценарий
«04_PlanTasksWithPredecessors.script»
из
папки data/scenarios/iteration_1. Отобразите
расписание для всех ресурсов, имеющихся в
системе.
Назначьте для задачи «Start-Up meeting»
ношение «Predecessor» с задачей «Cleaning».
Для этого выполните следующие действия:
Навигация → двойной щелчок по пункту
События → Создать → Изменить отношение
предшествования между задачами (Рисунок
59). Далее выберите предшествующую задачу – Cleaning (Рисунок 60) и следующую задачу – Start-up Meeting (аналогично).
Нажмите кнопку «Сохранить в базу данных»
на панели инструментов для сохранения
созданного события. Если этого не сделать,
при попытке запланировать событие
ется предупреждение (Рисунок 61).
Запланируйте событие «Изменить отношение предшествования между задачами».
Ожидаемый результат
Изначальное расписание должно
содержать событие недоступности ресурса для room №123 с
6:00 до 16:00 (Рисунок 58).
В закладке События можно видеть новое событие «Изменить
отношение
предшествования
между задачами».
105
Действия
Создайте событие создания задачи «Start-Up
Meeting». Для этого выполните следующие
действия: Навигация → двойной щелчок по
пункту События → Создать → Планирование новой задачи, выберите название задачи
«Start-Up Meeting».
Нажмите кнопку «Сохранить в базу данных»
на панели инструментов для сохранения
созданного события.
Ожидаемый результат
Операция «Resources unavailability» для ресурса room №123
запланирована с 6:00 до 16:00.
Задача «Cleaning» для ресурса
room №123 запланирована с
16:00 до 17:00.
Запланируйте событие «Start-Up Meeting». Задача «Start-Up Meeting» заплаОтобразите расписание для всех ресурсов в нирована для ресурсов John, Bill,
системе.
projector1 и room №123 с 17:00
до 19:00 (Рисунок 62).
Задача «Cleaning» автоматически
размещается
перед
задачей
«Start-Up Meeting», т.к. связана с
ней
отношением
предшествования, заданным в
онтологии.
Рисунок 58 – Начальное расписание
Рисунок 59 – Создание события предшествующей операции
106
Нажмите здесь
Рисунок 60 – Диалог выбора добавляемой задачи
Рисунок 61 – Предупреждение о попытке запланировать несохраненное
событие
Рисунок 62 – Итоговое расписание
5.7 Сценарий планирования задач с подзадачами
5.7.1 Описание сценария
Сценарий «iteration_1/05_PlanTasksWithSubtask.script» демонстрирует
возможность планирования задач, состоящих из ряда подзадач. Например, при
планировании задачи «Start-Up meeting» следующие подзадачи, необходимые
для ее реализации, автоматически планируются системой: «Complex Cleaning»
107
(эта задача также содержит подзадачи: «Washing windows» и «Washing floor») и
«Meeting» (они заданы в сцене). Подзадачи находятся в отношении «PartOf» с
основной задачей.
В данном примере задачи имеют отношение типа «PartOf» (называющиеся подзадачами – SubTasks).
5.7.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии планирования мероприятий, присутствующие в сцене, указаны ниже (Таблица 16).
Таблица 16 – Экземпляры концептов онтологии планирования мероприятий
Концепты онтологии
Ресурс
Экземпляры концептов
Участники:
­ John
­ Bill
Помещение:
­ room N123
Проектор:
­ projector1
Встреча:
­ Start-Up meeting
­ Meeting
­ ComplexCleaning
­ Windows washing
­ Floor washing
Задача
Значения атрибутов экземпляров концептов приведены ниже (Таблица 17).
Таблица 17 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«Start-Up meeting»
Задача
«Meeting»
Задача
«Complex Cleaning»
Задача
«Windows washing»
­
­
­
­
­
­
­
­
Значение атрибутов
Подзадачи (Subtasks) – ComplexCleaning, Meeting (Рисунок 63)
Предпочитаемое время (Preferred Time) – 15:00;
Длительность (Duration) – 2 часа;
Необходимые ресурсы (Required Resources):
John, Bill, projector1, room N123
Подзадачи (Subtasks) – Windows washing, Floor
washing (Рисунок 63)
Предпочитаемое время (Preferred Time) – 14:00;
Длительность (Duration) – 30 мин;
Необходимые ресурсы (Required Resources):
room N123
108
Экземпляр концепта
Задача
«Floor washing»
Значение атрибутов
­ Предпочитаемое время (Preferred Time) – 14:30;
­ Длительность (Duration) – 30 мин;
­ Необходимые ресурсы (Required Resources):
room N123
Рисунок 63 – Атрибуты задачи «Start-Up meeting» и «Complex Cleaning»
Значения атрибутов Meeting, Windows washing, Floor washing приведены
ниже (Рисунок 64).
Рисунок 64 – Атрибуты ресурсов подзадач
5.7.3 Этапы проведения эксперимента
Действия
Запустите систему. Загрузите сценарий «05_PlanTaskWithSubtask.script»
из папки data/scenarios/iteration_1.
Отобразите расписание для всех ресурсов, имеющихся в системе.
Запланируйте
задачу
«Start-Up
Meeting».
Ожидаемый результат
Начальное расписание не должно содержать операций для всех ресурсов и
задач.
Появившиеся задачи должны быть запланированы в предпочитаемое время
109
Действия
Ожидаемый результат
и не должны иметь временных конфликтов. Все ресурсы должны присутствовать на встрече в то же время.
Расписание для ресурса room №123
должно включать три операции:
Отобразите расписание для всех ре- «Windows Washing», «Floor washing» и
сурсов в системе.
«Meeting».
Расписание
других
сов должно включать операцию «Meeting» в 15:00 (Рисунок 65).
Рисунок 65 – Итоговое расписание
5.8 Сценарий планирования с выбрасыванием менее важных задач
5.8.1 Описание сценария
Сценарий «iteration_1/06_DropLessImportantTasks.script» демонстрирует
алгоритм выбрасывания задач с более низким приоритетом. Новая задача более
важна, чем уже запланированная, и требует того же временного интервала, что
и предыдущая, поэтому из расписания необходимо выбросить менее важную
задачу.
5.8.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии планирования мероприятий, присутствующие в сцене, указаны ниже (Таблица 18).
Значения атрибутов экземпляров концептов приведены в таблице
(Таблица 19).
Таблица 18 – Экземпляры концептов онтологии планирования мероприятий
Концепты онтологии
Ресурс
Экземпляры концептов
Участники:
­ John
­ Bill
Помещение:
110
Концепты онтологии
Экземпляры концептов
­ room N123
Проектор:
­ projector1
Встреча:
­ Start-Up meeting1
­ Start-Up meeting2
Задача
Таблица 19 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«Start-Up meeting1»
­
­
­
­
­
Задача
«Start-Up meeting2»
­
­
­
­
­
­
­
Значение атрибутов
Предпочитаемое время (Preferred Time) –
15:00;
Минимальное время начала (Min start time) –
15:00;
Максимальное время начала (Max start time) –
18:00;
Длительность (Duration) – 4 часа;
Необходимые ресурсы (Required Resources):
John, Bill, projector1, room N123;
Приоритет (Priority) – 2
Предпочитаемое время (Preferred Time) –
15:00;
Минимальное время начала (Min start time) –
15:00;
Максимальное время начала (Max start time) –
18:00;
Длительность (Duration) – 4 часа;
Необходимые ресурсы (Required Resources):
John, Bill, projector1, room N123;
Приоритет (Priority) – 1
5.8.3 Этапы проведения эксперимента
Действия
Ожидаемый результат
Запустите систему. Загрузите сценарий
«06_DropLessImportantTasks.script» Начальное расписание не должно содериз папки data/scenarios/iteration_1. жать операций для всех ресурсов.
Отобразите расписание для всех
ресурсов, имеющихся в системе.
Появившаяся задача «Start-Up Meeting1»
Запланируйте задачу «Start-Up
должна быть запланирована в ее предпоMeeting1».
читаемое время.
Отобразите расписание для всех Расписание ресурсов должно включать
ресурсов системы.
операцию «Start-Up Meeting1» в 15:00.
111
Действия
Ожидаемый результат
Задача «Start-Up Meeting2» должна выбрасывать операцию «Start-Up Meeting1»
и становиться запланированной в свое
Запланируйте задачу «Start-Up предпочитаемое время, потому что ее
Meeting2».
приоритет выше. На странице входящих
сообщений («Входящие») должно появиться сообщение о выбросе задачи.
(Рисунок 66).
Расписание ресурсов должно включать
Отобразите расписание для всех операцию «Start-Up Meeting2» в 15:00.
ресурсов в системе.
«Start-Up Meeting1» отсутствует в расписании (Рисунок 67).
Рисунок 66 – Сообщение о выбросе задачи
Рисунок 67 – Конечное расписание
5.8.4 Индивидуальные задания
1. Удалите у задачи «Start-Up Meeting1» минимальное и максимальное
время начала и перепланируйте ее, выбрав функции «Действие» и затем «Запланировать заново». Опишите полученный результат.
5.9 Сценарий с проактивностью агента операции
5.9.1 Описание сценария
Сценарий «iteration_1/07_OperationAgentProactivity.script» демонстрирует
проактивность агентов. Даже если задача уже запланирована, она старается занять наилучшую из возможных позиций в расписании.
В данном примере присутствуют две задачи, которые необходимо запланировать, с одним и тем же предпочитаемым временем. Одна из них планируется в предпочитаемое время, вторая – нет. Первая задача, запланированная в
112
предпочитаемое время, отменяется пользователем по какой-либо причине. Вторая задача в режиме проактивности должна перестроить расписание и занять
доступный интервал предпочитаемого времени.
5.9.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии планирования мероприятий, присутствующие в сцене, указаны ниже (Таблица 20).
Таблица 20 – Экземпляры концептов онтологии планирования мероприятий
Концепты онтологии
Ресурс
Экземпляры концептов
Участники:
­ John
­ Bill
Помещение:
­ room N123
Проектор:
­ projector1
Встреча:
­ Start-Up meeting1
­ Start-Up meeting2
Задача
Значения атрибутов экземпляров концептов приведены ниже (Таблица 21).
Таблица 21 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«Start-Up meeting1»
Задача
«Start-Up meeting2»
­
­
­
­
­
­
Значение атрибутов
Предпочитаемое время (Preferred Time) – 15:00;
Длительность (Duration) – 2 часа;
Необходимые ресурсы (Required Resources):
John, Bill, projector1, room N123
Предпочитаемое время (Preferred Time) – 15:00;
Длительность (Duration) – 2 часа;
Необходимые ресурсы (Required Resources):
John, Bill, projector1, room N123
5.9.3 Этапы проведения эксперимента
Действия
Ожидаемый результат
Запустите систему. Загрузите сценарий
«07_OperationAgentProactivity.script» из
Начальное расписание не должно сопапки data/scenarios/iteration_1. Отобрадержать операций для всех ресурсов.
зите расписание для всех ресурсов,
имеющихся в системе.
Задачи должны быть запланированы
Запланируйте задачи «Start-Up Meetдруг за другом по времени.
ing1» и «Start-Up Meeting2». Отобразите
ние ресурсов должно включать операсписание для всех ресурсов.
рации «Start-Up Meeting1» и «Start-Up
113
Действия
Ожидаемый результат
Meeting2» (Рисунок 68).
Посмотрите расписание в таблице для
ресурса «John» (Рисунок 68). Создайте
событие отмены задачи для задачи, которая была запланирована на 15:00
(Рисунок 69, Рисунок 70).
Нажмите кнопку «Сохранить в базу
данных» для сохранения созданной задачи.
Другая задача должна быть проактивно запланирована на ее предпочиЗапланируйте событие отмены задачи.
таемое время, так как этот интервал
освободился.
Расписание для ресурсов должно
Отобразите расписание для всех ресурвключать одну операцию в предпочисов.
таемое время – 15:00 (Рисунок 71).
Рисунок 68 – Запланированы задачи «Start-Up meeting1», «Start-Up meeting2»
114
Рисунок 69 – Создание события отмены задачи (Cancel Task)
Рисунок 70 – Назначение задачи для события отмены задачи
Рисунок 71 – Итоговое расписание
115
5.10 Сценарий, демонстрирующий понятие реального и модельного
времени в онтологии
5.10.1 Описание сценария
Сценарий «iteration_2/02_CurrentTimeOntology.script» демонстрирует понятие реального и модельного времени в системе мультиагентного планирования. Реальное время – это время обычных часов. Модельное время – это некоторый объект системы, имитирующий ход часов реального времени. Текущее
значение модельного времени пользователь системы может установить самостоятельно. Время планирования задачи изменяется в соответствии с текущим
значением модельного времени.
5.10.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии планирования мероприятий, присутствующие в сцене, указаны ниже (Таблица 22).
Таблица 22 – Экземпляры концептов онтологии планирования мероприятий
Концепты онтологии
Ресурс
Экземпляры концептов
Участники:
­ John
­ Bill
Помещение:
­ room N123
Проектор:
­ projector1
Встреча:
­ Start-Up meeting1
­ Start-Up meeting2
Задача
Модельное время
Значения атрибутов экземпляров концептов приведены ниже (Таблица 23).
Таблица 23 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«Start-Up meeting1»
Задача
«Start-Up meeting2»
­
­
­
­
­
­
­
­
Значение атрибутов
Минимальное время начала – 15:00;
Максимальное время начала – 15:30;
Предпочитаемое время (Preferred Time) – 15:00;
Длительность (Duration) – 2 часа;
Необходимые ресурсы (Required Resources):
John, Bill, projector1, room N123
Минимальное время начала – 17:00;
Максимальное время начала – 17:30;
Предпочитаемое время (Preferred Time) – 17:00;
116
Экземпляр концепта
Текущее значение модельного времени
Значение атрибутов
­ Длительность (Duration) – 2 часа;
­ Необходимые ресурсы (Required Resources):
John, Bill, projector1, room N123
­ 01/03/07 15:15
5.10.3 Этапы проведения эксперимента
Действия
Ожидаемый результат
Установите
текущее
значение
ного времени в системе на 01/03/07 Текущее значение модельного време15:15. Для этого откройте окно на- ни в системе должно стать 01/03/07
строек: Инструменты → Настройки → 15:15.
Модельное время (Рисунок 72).
Начальное расписание не должно соЗагрузите
сценарий
держать операций для всех ресурсов и
«02_CurrentTimeInOntology.script» из
задач. Задачи и соответствующие сопапки data/scenarios/iteration_2/.
бытия должны быть загружены.
Задача не может быть запланирована в
предпочитаемое время 15:00. Текущее
значение модельного времени не
вышает
максимального
времени
Запланируйте задачу «Start-Up meeting
ла, заданного в онтологии, поэтому
1».
дача должна быть запланирована в
15:15 и не должна иметь временных
конфликтов. Ресурс должен присутствовать на встрече в 15:15 (Рисунок 73).
Задача не может быть запланирована в
предпочитаемое время 17:00. Текущее
значение модельного времени не
вышает
максимального
времени
Запланируйте задачу «Start-Up meeting
ла, заданного в онтологии, поэтому
2».
дача должна быть запланирована в
17:15 и не должна иметь временных
конфликтов. Ресурс должен присутствовать на встрече в 17:15 (Рисунок 74).
117
Рисунок 72 – Нстройки
Рисунок 73 – Расписание после первой запланированной встречи
Рисунок 74 – Итоговое расписание
5.10.4 Индивидуальные задания
1. Загрузите сценарий «03_SystemCurrentTime.script» из папки
data/scenarios/iteration_2/. По онтологии и сцене определите значения атрибутов
экземпляров концептов. Установите текущее значение модельного времени
01/03/07 15:00. Запланируйте задачи. Объясните полученные результаты.
5.11 Сценарий, демонстрирующий использование времени заморозки
5.11.1 Описание сценария
Сценарий «iteration_2/04_FreezeTime.script» демонстрирует использование времени заморозки в системе мультиагентного планирования. Время заморозки – это интервал времени, отсчитываемый от текущего значения модельного времени, на который можно сдвинуть время выполнения задач. Время начала
задач, запланированных до интервала заморозки, не изменяется. Время начала
118
задач, запланированных в интервале заморозки, сдвигается на величину этого
интервала.
5.11.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии планирования мероприятий, присутствующие в сцене, указаны ниже (Таблица 24).
Таблица 24 – Экземпляры концептов онтологии планирования мероприятий
Концепты онтологии
Ресурс
Экземпляры концептов
Участники:
­ John
­ Bill
Помещение:
­ room N123
Проектор:
­ projector1
Встреча:
­ Start-Up meeting1
­ Start-Up meeting2
Задача
Время заморозки
Значения атрибутов экземпляров концептов приведены ниже (Таблица 25).
Таблица 25 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«Start-Up meeting1»
­
­
­
­
­
Задача
«Start-Up meeting2»
­
­
­
­
­
Время заморозки
­
Значение атрибутов
Минимальное время начала – 14:00;
Максимальное время начала – 14:10;
Предпочитаемое время (Preferred Time) – 14:00;
Длительность (Duration) – 1 час;
Необходимые ресурсы (Required Resources):
John, Bill, projector1, room N123
Минимальное время начала – 15:00;
Максимальное время начала – 15:30;
Предпочитаемое время (Preferred Time) – 15:00;
Длительность (Duration) – 2 часа;
Необходимые ресурсы (Required Resources):
John, Bill, projector1, room N123
15 минут
5.11.3 Этапы проведения эксперимента
Действия
Ожидаемый результат
Загрузите
сценарий Певоначально в расписании содержится запла«04_FreezeTime.script» из пап- нированная операция «Start-Up meeting 1»
ки data/scenarios/iteration_2/.
(Рисунок 75).
119
Действия
Ожидаемый результат
Задача должна быть запланирована на 15:15 с
Запланируйте задачу «Start-Up учетом времени заморозки. Ресурс должен
meeting 2».
присутствовать на встрече в 15:15 (Рисунок
76).
Рисунок 75 – Запланирована задача «Start-Up Meeting 1»
Рисунок 76 – Итоговое расписание
5.12 Сценарий, демонстрирующий режим подтверждения задачи
5.12.1 Описание сценария
Сценарий «iteration_2/05_TaskConfirmation.script» демонстрирует работу с
двумя задачами, у которых имеется атрибут «необходимо подтверждение»
(«must be confirmed»). Пользователь планирует две задачи с включенной опцией «необходимо подтверждение» и две без нее. Через некоторое время он отмечает, что одна из задач, требующих подтверждения, выполнена, а другая нет.
Поскольку вторая задача не выполнена в срок (значение текущего времени стало больше времени окончания выполнения операции в расписании), то она автоматически перепланируется на более позднее время.
5.12.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии планирования мероприятий, присутствующие в сцене, указаны ниже (Таблица 26).
Таблица 26 – Экземпляры концептов онтологии планирования мероприятий
120
Концепты онтологии
Ресурс
Экземпляры концептов
Участники:
­ John
­ Bill
Помещение:
­ room N123
Проектор:
­ projector1
Встреча:
­ Start-Up meeting1
­ Start-Up meeting2
­ Cleaning
­ Chair Repairing
Задача
Текущее время
Значения атрибутов экземпляров концептов приведены ниже (Таблица 27).
Таблица 27 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«Cleaning»
­
­
­
­
­
Задача
«Start-Up meeting1»
­
­
­
­
­
­
Задача
«Start-Up meeting2»
­
­
­
­
­
Задача
«Chair Repairing»
­
­
­
Значение атрибутов
Минимальное время начала – 01/03/07 13:00;
Максимальное время начала – 01/03/07 20:00;
Предпочитаемое время (Preferred Time) –
01/03/07 13:00;
Длительность (Duration) – 1 час;
Необходимые ресурсы (Required Resources):
room N123
Требуется подтверждение – true
Минимальное время начала – 01/03/07 14:00;
Максимальное время начала – 01/03/07 14:10;
Предпочитаемое время (Preferred Time) –
01/03/07 14:00;
Длительность (Duration) – 2 часа;
Необходимые ресурсы (Required Resources):
John, Bill, projector1, room N123
Минимальное время начала – 01/03/07 16:00;
Максимальное время начала – 16:30;
Предпочитаемое время (Preferred Time) – 16:00;
Длительность (Duration) – 2 часа;
Необходимые ресурсы (Required Resources):
John, Bill, projector1, room N123
Минимальное время начала – 01/03/07 18:00;
Максимальное время начала – 01/03/07 20:10;
Предпочитаемое время (Preferred Time) –
121
Экземпляр концепта
­
­
Текущее время
­
­
Значение атрибутов
01/03/07 18:00;
Длительность (Duration) – 0,5 часа;
Необходимые ресурсы (Required Resources):
John, room N123
Требуется подтверждение – true
28/02/07 00:00
5.12.3 Этапы проведения эксперимента
Действия
Загрузите
сценарий
«05_TaskConfirmation.script» из папки data/scenarios/iteration_2/.
Запланируйте задачу: «Cleaning»,
«Start-Up Meeting 1», «Start-Up
Meeting 2», «Chair repairing».
Поставьте текущее время на
01/03/07 19.00. Для этого проделайте Инструменты → Настройки →
Модельное время (Рисунок 78).
Зайдите на закладку Навигация →
Подтверждение задачи, отметьте задачу «Cleaning» как выполненную
(Выполнена) и щелкните кнопку
ОK. (Рисунок 78). В открывшемся
диалоге выберите «Да».
Ожидаемый результат
Начальное расписание не должно содержать операций для всех ресурсов и задач.
Задачи и соответствующие события
должны быть загружены.
Появившиеся задачи должны быть
планированы в предпочитаемое время и
не
должны
иметь
временных
тов. Все ресурсы должны присутствовать
на встрече в то же время (Рисунок 77).
Текущее время должно измениться.
Задача «Chair repairing» должна быть автоматически перепланирована на 19:00
(Рисунок 79).
122
Рисунок 77 – Запланированные задачи
Рисунок 78 – Подтверждение задачи Cleaning
Рисунок 79 – Итоговое расписание
5.13 Сценарий с изменением предпочитаемого времени /
минимального / максимального времени начала задачи
5.13.1 Описание сценария
Сценарий «iteration_2/06_ReplanTaskEvent.script» демонстрирует возможность пользователя перепланировать задачу. А именно, пользователь может изменить определенные атрибуты в запланированных задачах после планирования и перепланировать задачи.
5.13.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии планирования мероприятий, присутствующие в сцене, указаны ниже (Таблица 28).
Таблица 28 – Экземпляры концептов онтологии планирования мероприятий
123
Концепты онтологии
Ресурс
Экземпляры концептов
Участники:
­ John
­ Bill
Помещение:
­ room N123
Проектор:
­ projector1
Встреча:
­ Start-Up meeting1
­ Start-Up meeting2
Задача
Значения атрибутов экземпляров концептов приведены ниже (Таблица 29).
Таблица 29 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«Start-Up meeting1»
Задача
«Start-Up meeting2»
­
­
­
­
­
­
­
­
­
­
Значение атрибутов
Предпочитаемое время (Preferred Time) – 14:00;
Минимальное время начала: 01/03/07 14:00;
Максимльное время начала: 01/03/07 14:00;
Длительность (Duration) – 2 часа;
Необходимые ресурсы (Required Resources):
John, Bill, projector1, room N123
Предпочитаемое время (Preferred Time) – 15:00;
Минимальное время начала: 01/03/07 15:00;
Максимльное время начала: 01/03/07 19:00;
Длительность (Duration) – 2 часа;
Необходимые ресурсы (Required Resources):
John, Bill, projector1, room N123
5.13.3 Этапы проведения эксперимента
Действия
Ожидаемый результат
Запустите систему. Загрузите сценаНачальное расписание не должно сорий «06_ReplanTaskEvent.script» из
держать операций для всех ресурсов.
папки data/scenarios/iteration_2/.
Задачи должны быть запланированы
Запланируйте задачи «Start-Up Meet- друг за другом во времени. Расписание
ing1» и «Start-Up Meeting2». Отобрази- ресурсов должно включать операции
те расписание для всех ресурсов.
«Start-Up Meeting1» и «Start-Up Meeting2» (Рисунок 80).
Измените атрибуты Предпочитаемое
время и Минимальное время начала
задачи «Start-Up Meeting1» с 14:00 на
13:00. Для этого перейдите на вкладку
«Сцена», затем двойной щелчок на
124
Действия
«Задача», выберите задачу «Start-Up
Meeting1», нажмите кнопку «Детали»
(Рисунок 81).
Создайте событие «Перепланирование
задачи»
для
задачи
«Start-Up
Meeting1». Для этого перейдите на
вкладку «Навигация», затем События
→ Создать (Рисунок 82).
Нажмите кнопку «Сохранить в базу
данных» для сохранения событий
Ожидаемый результат
Задача «Start-Up Meeting2» должна
проактивно запланироваться в ее
Запланируйте событие «Перепланиро- предпочитаемое время. Задача «Startвание задачи»
Up Meeting1», которая была перепланирована, должна запланироваться в
13:00 (Рисунок 83).
Рисунок 80 – Первоначальное расписание
125
Редактировать здесь
Рисунок 81 – Изменение времени планирования задачи
Рисунок 82 – Создание события перепланирования задачи
Рисунок 83 – Итоговое расписание
126
5.14 Сценарий планирования задач с перемещением операций на
удобное время
5.14.1 Описание сценария
Сценарий «iteration_4/01_OperationJumps.script» демонстрирует работу
алгоритма перемещения задачи в ранее запланированном расписании в более
удобное время (operation jump).
5.14.2 Начальное состояние сцены
Начальное расписание содержит некоторые операции для ресурсов. Экземпляры концептов онтологии производства, присутствующие в сцене, указаны ниже (Таблица 30).
Таблица 30 – Экземпляры концептов онтологии производства
Концепты онтологии
Ресурс
Задача
Экземпляры концептов
Участники:
­ Bill
­ Bob
Помещение:
­ Discuss room
Задача:
­ Обсудить планы
­ Недоступность ресурса
Значения атрибутов экземпляров концептов приведены ниже (Таблица 31).
Таблица 31 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«Обсудить планы»
Задача
«Недоступность ресурса»
­
­
­
­
­
­
Значение атрибутов
Предпочитаемое время – 10:00
Максимальная длительность – 60 минут
Необходимые ресурсы – Bob, Bill, Discuss
room
Предпочитаемое время – 10:40
Максимальная длительность – 20 минут
Необходимые ресурсы – Bill
5.14.3 Этапы проведения эксперимента
Действия
Ожидаемый результат
Начальное расписание содержит некоЗагрузите
сценарий
торые операции для ресурсов. Задачи
«01_OperationJumps.script» из папки
и соответствующие события должны
data/scenarios/iteration_4.
быть загружены (Рисунок 84).
Запланируйте задачу «Обсудить пла- Появившаяся задача должна быть заны».
планирована на 10:20. Ресурсы долж127
Действия
Ожидаемый результат
ны присутствовать на встрече в 10:20
(Рисунок 85).
Запланируйте
событие
«Resource Ранее запланированные операции
unavailability» для Bill с 10:40 до 11:00. должны переместиться.
Расписание для Bob, Bill и Room
должно включать операцию «ОбсуОтобразите расписание для всех ре- дить планы» в 8:00. Также расписание
сурсов, имеющихся в системе.
для Bill должно включать операцию
«Resource Unavailability» в 10:40
(Рисунок 86).
Рисунок 84 – Начальное расписание
Рисунок 85 – Задача «Обсудить планы» запланирована
Рисунок 86 – Итоговое расписание для всех ресурсов
5.14.4 Индивидуальные задания
1.
Загрузите
сценарий
«01_OperationJumps.script»
из
папки
data/scenarios/iteration_4. Запланируйте первое событие. Зайдите в сцену и добавьте еще одного участника с именем «John». Запланируйте второе событие.
Опишите полученный результат.
128
2. Загрузите сценарий «01_OperationJumps.script» из папки data/scenarios/iteration_4. Зайдите в редактирование задачи и выберите у нее стратегию перепланирования “Отмена». Запланируйте первое событие. Зайдите в
сцену и добавьте еще одного участника с именем «John». Запланируйте второе
событие. Опишите полученный результат.
5.15 Сценарий с предложением пользователю вариантов разрешения
конфликтных ситуаций
5.15.1 Описание сценария
Сценарий «iteration_2/07_SuggestOptionsToUser.script» демонстрирует
возможность системы предлагать некоторые варианты разрешения конфликтных ситуаций в процессе планирования. При этом пользователь сам должен
принимать решение о том, как система должна планировать задачу.
5.15.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии планирования мероприятий, присутствующие в сцене, указаны ниже (Таблица 32).
Таблица 32 – Экземпляры концептов онтологии планирования мероприятий
Концепты онтологии
Ресурс
Событие
Задача
Экземпляры концептов
Участники:
­ John
­ Bill
Недоступность ресурса John
Встреча:
­ Start-Up meeting1
­ Start-Up meeting2
Значения атрибутов экземпляров концептов приведены ниже (Таблица 33).
Таблица 33 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«Start-Up meeting1»
­
­
­
­
Задача
«Start-Up meeting2»
­
­
­
­
­
Значение атрибутов
Предпочитаемое время (Preferred Time) –
01/01/06 11:00;
Длительность (Duration) – 3 часа;
Приоритет (Priority) – 8;
Необходимые ресурсы (Required Resources):
John, Bill
Предпочитаемое время (Preferred Time) –
01/01/06 08:00;
Минимальное время начала: 01/01/06 08:00;
Максимльное время начала: 01/01/06 08:00;
Длительность (Duration) – 4 часа;
Приоритет (Priority) – 9;
129
Экземпляр концепта
Значение атрибутов
­ Необходимые ресурсы (Required Resources):
John, Bill
Событие недоступности для ресурса John имеет временной интервал с
14:00 до 18:00.
5.15.3 Этапы проведения эксперимента
Действия
Загрузите сценарий
«07_SuggestOptionsToUser.script” из
папки data/scenarios/iteration_2/.
Запланируйте
событие
navailability» для ресурса John и задачу «Start-Up meeting1» (Рисунок 87).
Ожидаемый результат
Начальное расписание не должно содержать операций для всех ресурсов.
Событие и задача должны успешно запланироваться (Рисунок 88).
Задача не должна запланироваться по
Запланируйте задачу «Start-Up meetпричине нехватки ресурсов (Рисунок
ing2».
89).
Выберите событие создания задачи
«Start-Up Meeting2» и нажмите кноп- Должна открыться таблица «Варианты
ку «Действия» → «Показать вариан- решения проблем» (Рисунок 90).
ты разрешения проблем».
Выберите вариант уменьшения длиДлительность
«Start-Up
meeting1»
тельности задачи и щелкните по
должна уменьшиться до 120 минут и
кнопке «Применить». Затем нажмите
задача должна запланироваться с 12:00
кнопку «Старт» на главной панели
до 14:00 (Рисунок 91).
для запуска планирования.
Рисунок 87 – Атрибуты события недоступности ресурса John
130
Рисунок 88 – Начальное расписание
Рисунок 89 – Вторая задача не запланировалась
Рисунок 90 – Уменьшение времени выполнения первой задачи для разрешения
конфликта
Рисунок 91 – Итоговое расписание
5.15.4 Индивидуальные задания
1. Опишите, какие еще могут быть варианты разрешения проблемной ситуации по Вашему мнению.
131
5.16 Контрольные вопросы
1. Что такое онтология? В чем отличие базовой онтологии и онтологии
предметной области?
2. Перечислите основные концепты базовой онтологии.
3. Перечислите основные концепты онтологии планирования мероприятий.
4. Как запланировать событие?
5. Какие атрибуты операции отображается в автоматизированной системе
адаптивного планирования?
6. Как запланировать недоступность ресурса? Как может повлиять недоступность ресурса на расписание выполнения операций?
7. В каком случае происходит сдвиг цепочки ранее запланированных операций?
8. Каковы условия выполнения задачи с предшественниками?
9. Как создать событие предшествующей операции для задачи?
10. Как определяется задача с подзадачами? Каковы особенности планирования задачи с подзадачами?
11. В каком случае происходит выбрасывание задачи из расписания?
12. Что такое проактивность агента операции? В каком случае отрабатывает режим проактивности агента операции?
132
6 ЛАБОРАТОРНАЯ РАБОТА №2. ПЛАНИРОВАНИЕ
ТЕХНОЛОГИЧЕСКОГО ПРОЦЕССА ПРОИЗВОДСТВА НА
ОСНОВЕ ЗНАНИЙ, ПРЕДСТАВЛЕННЫХ В ОНТОЛОГИИ
6.1 Цели и задачи лабораторной работы
В мультиагентных системах онтология является эффективным и наглядным средством представления знаний о предметной области решаемой задачи.
Онтология производства содержит две типовые онтологии, которые могут быть
применены для описания технологических процессов на различных машиностроительных предприятиях:
­ онтология процесса изготовления зеркала заднего вида,
­ онтология процесса изготовления крепежного изделия «Болт».
Цель лабораторной работы № 2 – продемонстрировать возможности
онтологий для представления знаний о технологическом процессе производства, показать, как изменение атрибутов в онтологии влияет на результат планирования.
В процессе выполнения лабораторной работы № 2 решаются следующие
задачи:
­ Изучение приемов представления знаний о технологическом процессе производства в виде онтологии производства.
­ Освоение приемов конструирования и моделирования онтологической сцены для сложных задач планирования индивидуального или группового расписаний.
­ Освоение использования агентов для адаптивного планирования событий.
­ Изучение сценариев, реализующих различные алгоритмы планирования технологических процессов производства.
­ Изучение влияния изменения атрибутов в онтологии на результат планирования.
6.2 Онтология производства
Онтология производства содержит следующие концепты:
­ Деталь,
­ Наследники концепта базовой онтологии Задача (основные производственные операции) (Рисунок 92):
o Изготовить изделие:
 Изготовить изделие Болт 728,
 Изготовить зеркало,
 Изготовить скобу,
o Собрать Изделие:
 Изготовить изделие Струбцина.
­ Наследники концепта базовой онтологии Ресурс (Рисунок 93):
o Исполнитель:
 Контролер,
133
 Рабочий,
o Оборудование.
Иерархия классов в виде дерева концептов представлена в левом окне, а в
виде семантической сети – в среднем окне. Например, концепт Ресурс имеет
две разновидности (подклассы): Исполнитель и Оборудование. В свою очередь,
класс Исполнитель также имеет две разновидности: Контролер и Рабочий. В
нижнем правом окне показаны атрибуты концепта Исполнитель, выделенного в
дереве концептов (Рисунок 94).
Рисунок 92 – Наследники концепта базовой онтологии Задача
134
Рисунок 93 – Наследники концепта базовой онтологии Ресурс
Рисунок 94 – Иерархия классов концепта Ресурс, представленная в виде дерева
концептов и семантической сети
Иерархия классов концепта Деталь, представленная в виде семантической
135
сети, показана на (Рисунок 95).
Рисунок 95 – Иерархия классов концепта Деталь
Иерархия классов концепта Задача, представленная в виде семантической
сети, показана на (Рисунок 96). Основные задачи состоят из вспомогательных
операций (подзадач), например, Отторцевать, Проточить, Нарезать резьбу и т.п.
Рисунок 96 – Иерархия классов концепта Задача
Подзадачи, представляющие собой операции, из которых состоит слож136
ная задача, должны выполняться в определенной последовательности и имеют
определенную продолжительность. Связи концепта-задачи с концептамиподзадачами показаны синими линиями, а связи между концептамиподзадачами в порядке их выполнения показаны красными линиями (Рисунок
97). Для того чтобы отобразить последовательность выполнения операций, из
которых состоит сложная задача, необходимо перейти на второй уровень детализации при отображении семантической сети и выбрать опцию “Зависимости
задач” в поле “Выберите связи”.
Рисунок 97 – Последовательность операций при выполнении задачи
«Изготовить изделие Болт 028»
При выполнении задачи необходимо учитывать, кроме последовательности операций, их продолжительность, а также минимально и максимально допустимое время начала операции и предпочитаемое время выполнения операции. Это необходимо для того, чтобы можно было применить ту или иную
стратегию планирования расписания задач.
Для задач определяется приоритет: чем меньше значение приоритета, тем
он выше.
Кроме основных атрибутов, которые указаны в базовой онтологии, наследники концепта Задача имеют дополнительные атрибуты, такие как описание подзадач. Например, концепт «Изготовить изделие Болт 028» содержит атрибуты, определяющие подзадачи:
­ Охлаждение (отпуск), доотпуск,
­ Торцевать, Точить, Отрезать,
­ Проточить, Нарезать резьбу, Отторцевать и т.д.
137
Требования задачи к ресурсам в онтологии производства определяются
аналогично требованиям к ресурсам в онтологии планирования мероприятий (п.
5.2 Онтология планирования мероприятий). Однако, спецификой онтологии
производства является то, что обычно требование состоит из двух частей:
­ требование на рабочего,
­ требование на оборудование.
Подробно пример определения требований к ресурсам в онтологии производства описан в п. 6.4 Сценарий планирования с учетом требований к ресурсам, заданных в онтологии.
6.3 Сценарий поиска ресурсов для задачи
6.3.1 Описание сценария
Сценарий «iteration_3/01_FindingResources.script» демонстрирует возможность подбора ресурсов для задачи. Для выполнения задачи необходимы
рабочий и сверлильный станок. В сцене задано два станка (сверлильный и фрезерный) и два рабочих. Один из рабочих недоступен некоторое время, так что
задача не сможет запланироваться для него в предпочитаемое время. Задача
должна будет выбрать сверлильный станок и свободного рабочего и запланироваться для них.
6.3.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии производства, присутствующие в сцене, указаны ниже (Таблица 34). Значения атрибутов экземпляров концептов приведены ниже (Таблица 35).
Таблица 34 – Экземпляры концептов онтологии производства
Концепты онтологии
Ресурс
Задача
Экземпляры концептов
Рабочие:
­ И.Иванов
­ П.Петров
Оборудование:
­ Вертикально-фрезерный станок
­ Сверлильный станок
Задача:
­ Сверлить Контровка
Таблица 35 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«Сверлить Контровка»
Значение атрибутов
­ Предпочитаемое время (Preferred Time) – 10:00;
­ Максимальная длительность (Max Duration) –
40 минут
6.3.3 Этапы проведения эксперимента
Действия
Ожидаемый результат
138
Действия
Загрузите
сценарий
«01_FindingResources.script» из
папки data/scenarios/iteration_3/.
Запланируйте событие «Resource
unavailability» для «И.Иванов» с
10:00 до 11:00.
Ожидаемый результат
Начальное расписание не должно содержать
операций для всех ресурсов.
Запланировано
событие
«Resource
unavailability» для «И.Иванов» с 10:00 до
11:00 (Рисунок 98).
В онтологии определено, что задача «Сверлить Контровка» требует для своего выполнения сверлильный станок (Рисунок 99).
Задача «Сверлить Контровка» оценивает
возможный конфликт при размещении на
ресурсах «И.Иванов» и «П.Петров» по криЗапланируйте событие «Plan new терию минимального суммарного времени
task» для задачи «Сверлить Кон- пересечения с ранее запланированными разтровка».
мещениями. «И.Иванов» в Предпочитаемое
время задачи «Сверлить Контровка» недоступен, а «П.Петров» свободен все время.
Поэтому задача «Сверлить Контровка» планируется в Предпочитаемое время 10:00 на
«П.Петрова», и на сверлильный станок
(Рисунок 100).
Рисунок 98 – Планирование события недоступности рабочего И.Иванова
Рисунок 99 – Тип станка, требуемый для выполнения операции «Сверлить
Контровка»
139
Рисунок 100 – Планирование операции «Сверлить Контровка» в соответствии с
требуемым типом станка
6.3.4 Индивидуальные задания
1. Необходимо выполнить задачу «Сделать шестигранник», предпочитаемое время – 11:00, максимальное время выполнения – 1 час. Создайте ресурсы
«И.Иванов», «П.Петров», сверлильный станок, вертикально-фрезерный станок.
Подберите ресурсы для задачи «Сделать шестигранник» при условии недоступности ресурса «П.Петров» с 9:00 до 12:00 и недоступности ресурса
«И.Иванов» с 10:00 до 11:00.
6.4 Сценарий планирования с учетом требований к ресурсам,
заданных в онтологии
6.4.1 Описание сценария
Сценарий «iteration_3/02_SchedulingAccordingRequirements.script» демонстрирует, каким образом требования к ресурсам, определенные в онтологии,
учитываются при планировании задачи. Для выполнения задачи требуется рабочий категории не ниже 4 и сверлильный станок. В сцене задано двое рабочих
с разными категориями (2 и 3) и два станка (сверлильный и вертикальнофрезерный). Задача не планируется.
Вводится новый рабочий с категорией 5. Задача повторно планируется.
Задача должна запланироваться на рабочего с категорией 5 и сверлильный станок.
6.4.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии производства, присутствующие в сцене, указаны ниже (Таблица 36).
Таблица 36 – Экземпляры концептов онтологии производства
Концепты онтологии
Ресурс
Экземпляры концептов
Рабочие:
­ И.Иванов
­ П.Петров
Оборудование:
140
Концепты онтологии
Экземпляры концептов
­ Вертикально-фрезерный станок
­ Сверлильный станок
Задача
Задача:
­ Сверлить Контровка
Значения атрибутов экземпляров концептов приведены ниже (Таблица 37).
Таблица 37 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Ресурс «И.Иванов»
Ресурс «П.Петров»
Задача
«Сверлить Контровка»
Значение атрибутов
­ Разряд – 2
­ Разряд – 3
­ Предпочитаемое время (Preferred Time) –
10:00;
­ Максимальная длительность (Max Duration) –
40 минут;
­ Требования к исполнителям – разряд рабочего не ниже 4
6.4.3 Этапы проведения эксперимента
Действия
Ожидаемый результат
Загрузите
сценарий
«02_SchedulingAccordingRequirements. Начальное расписание не должно соscript»
из
папки
da- держать операций для всех ресурсов.
ta/scenarios/iteration_3/.
Задача «Сверлить Контровка» не заЗапланируйте первое из двух событий
планируется (Рисунок 101), т.к. требу«Plan new task» для задачи «Сверлить
ет для своего выполнения рабочего с
Контровка»
квалификацией более 3 (Рисунок 102).
Введите в сцену рабочего «С. Сидоров» с квалификацией 5. Для этого
выполните Сцена → Ресурс (+) → ИсВ сцену добавлен рабочий «С. Сидополнитель (+) → Исполнитель (двойров» с квалификацией 5.
ной клик) → Создать → Имя → ввести
«С. Сидоров» → Rank → ввести «5» →
OK (Рисунок 103).
Задача «Сверлить Контровка» заплаЗапланируйте оставшееся событие
нирована в предпочитаемое время
«Plan new task» для задачи «Сверлить
10:00 на С.Сидорова и на сверлильный
Контровка».
станок (Рисунок 104).
141
Рисунок 101 – Задача не запланирована
Рисунок 102 – Требования к разряду рабочего для выполнения операции
«Сверлить Контровка»
Рисунок 103 – Создание нового рабочего с требуемым разрядом
Рисунок 104 – Итоговое расписание
6.4.4 Индивидуальные задания
1. Необходимо выполнить задачу «Сделать шестигранник», предпочитае142
мое время – 11:00, максимальное время выполнения – 1 час. Определите в онтологии, какие ресурсы требуются для выполнения задачи «Сделать шестигранник». Создайте ресурсы «И.Иванов» с разрядом 2, «П.Петров» с разрядом
3, «С.Сидоров» с разрядом 4, сверлильный станок, вертикально-фрезерный станок. Подберите ресурсы для задачи «Сделать шестигранник» при условии недоступности ресурса «П.Петров» с 9:00 до 12:00.
2. Необходимо выполнить задачу «Изготовить скобу», предпочитаемое
время – 10:00, максимальное время выполнения – 45 мин. Определите в онтологии, какие ресурсы требуются для выполнения задачи «Изготовить скобу».
Создайте ресурсы «И.Иванов» с разрядом 3, «П.Петров» с разрядом 4,
«С.Сидоров» с разрядом 5, сверлильный станок, вертикально-фрезерный станок, пресс. Подберите ресурсы для задачи «Изготовить скобу» при условии недоступности ресурса «И.Иванов» с 9:00 до 10:00, ресурса «С.Сидоров» с 9:00 до
12:00.
6.5 Сценарий планирования сложной задачи на основе ее описания в
онтологии
6.5.1 Описание сценария
Сценарий «iteration_3/03_SchedulingComplexTask.script» демонстрирует,
каким образом осуществляется планирование сложной задачи, состоящей из
нескольких подзадач, на основе описания сложной задачи в онтологии. Выполняется планирование задачи изготовления зеркала заднего вида, состоящей из
нескольких подзадач. Станок, на котором будет осуществляться самая первая
операция по производству зеркала, недоступен, поэтому при планировании задача по производству зеркала должна быть смещена на более позднее время.
6.5.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии производства, присутствующие в сцене, указаны ниже (Таблица 38). Значения атрибутов экземпляров концептов приведены ниже (Таблица 39).
Таблица 38 – Экземпляры концептов онтологии производства
Концепты онтологии
Ресурс
Задача
Экземпляры концептов
Рабочие:
­ И.Иванов
Оборудование:
­ Пресс
­ Станок резки стекла
­ Станок для клейки стекла
­ Инструмент для монтажа корпуса зеркала к
корпусу автомобиля
Задача:
­ Изготовить зеркало заднего вида
143
Таблица 39 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Ресурс «И.Иванов»
Задача
«Изготовить зеркало
заднего вида»
Значение атрибутов
­ Разряд – 6
­ Предпочитаемое время (Preferred Time) –
10:00
6.5.3 Этапы проведения эксперимента
Действия
Ожидаемый результат
Загрузите сценарий
Начальное расписание не должно содер«03_SchedulingComplexTask.script»
жать операций для всех ресурсов.
из папки data/scenarios/iteration_3/.
Последовательность операций для выполнения задачи «Изготовить зеркало заднего
вида» определена в онтологии. Последовательность операций можно видеть при
выборе пункта «Зависимости задач» в поле «Выберите связи» (уровень детализаЗапланируйте событие «Resource ции – 2) для всей задачи в целом (Рисунок
unavailability» для «Пресс» с 07:00 105) и для каждой из операций (Рисунок
до 09:00.
106). Первая операция «Сделать корпус»
требует для своего выполнения оборудование «Пресс», что определено в онтологии производства (Рисунок 107).
Запланировано
событие
«Resource
unavailability» для «Пресс» с 07:00 до
09:00 (Рисунок 108).
Выполнение цепочки операций по выполЗапланируйте событие «Plan new нению задачи «Изготовить зеркало заднеtask» для задачи «Изготовить зер- го вида» смещается с предпочтительного
кало заднего вида».
времени на более позднее время (Рисунок
109).
144
Рисунок 105 – Последовательность операций для выполнения сложной задачи
«Изготовить зеркало заднего вида»
145
Рисунок 106 – Предшествование операций для выполнения задачи «Изготовить
зеркало заднего вида»
Рисунок 107 – Требования к оборудованию операции «Сделать корпус»
146
Рисунок 108 – Запланировано событие недоступности оборудования «Пресс»
Рисунок 109 – Итоговое расписание при планировании сложной задачи,
состоящей из нескольких операций
6.5.4 Индивидуальные задания
1. Необходимо выполнить задачу «Изготовить изделие Струбцина»,
предпочитаемое время – 11:00. Определите в онтологии, какие операции входят
в состав задачи «Изготовить изделие Струбцина» и какие ресурсы оборудования требуются для выполнения этих операций. Создайте необходимые ресурсы
оборудования. Задайте длительность операций. Для выполнения операции
«Сборка» необходим «Пресс», который недоступен с 08:00 до 09:00. Запланируйте выполнение задачи «Изготовить изделие Струбцина».
2. Необходимо выполнить задачу «Изготовить изделие Струбцина»,
предпочитаемое время – 11:00. Определите в онтологии, какие операции входят
в состав задачи «Изготовить изделие Струбцина» и какие ресурсы исполнителей требуются для выполнения этих операций. Задайте длительность операций.
Создайте ресурсы «И.Иванов» с категорией 4 и «П.Петров» с категорией 5.
«П.Петров» недоступен с 08:00 до 09:00. Запланируйте выполнение задачи «Из147
готовить изделие Струбцина».
6.6 Сценарий планирования задач с вытеснением запланированной
задачи на другой ресурс
6.6.1 Описание сценария
Сценарий «iteration_3/05_DisplacementScheduledTasktoAnotherResource.script»
демонстрирует возможность замены ресурса у задачи в случае, если размещение на исходном ресурсе невозможно. В данном сценарии рассматривается
случай, когда приходит новая более приоритетная задача и вытесняет уже запланированную задачу на другой ресурс.
6.6.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии производства, присутствующие в сцене, указаны ниже (Таблица 40).
Таблица 40 – Экземпляры концептов онтологии производства
Концепты онтологии
Ресурс
Задача
Экземпляры концептов
Рабочие:
­ И.Иванов
­ П.Петров
Оборудование:
­ Вертикально-фрезерный станок
­ Сверлильный станок
Задача:
­ Сверлить Контровка
­ Сделать Шестигранник
Значения атрибутов экземпляров концептов приведены ниже (Таблица 41).
Таблица 41 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Ресурс «И.Иванов»
Ресурс «П.Петров»
Задача
«Сверлить Контровка»
Задача
«Сделать Шестигранник»
­
­
­
­
­
­
­
­
­
Значение атрибутов
Разряд – 6
Разряд – 6
Приоритет – 5
Минимальное время начала – 10:30
Предпочитаемое время – 11:00
Максимальная длительность – 120 минут
Приоритет – 1
Предпочитаемое время – 12:00
Максимальная длительность – 240 минут
6.6.3 Этапы проведения эксперимента
Действия
Ожидаемый результат
Загрузите
сценарий Начальное расписание не должно содержать опе148
Действия
Ожидаемый результат
«05_DisplacementScheduled раций для ресурсов.
TaskToAnotherResource.script» из папки data/scenarios/iteration_3/.
Запланируйте
событие
«Resource
unavailability» Запланировано событие «Resource unavailability»
для «И.Иванов» с 12:30 до для «И. Иванов» с 12:30 до 18:00.
18:00.
Задача «Сверлить Контровка» требует для своего
выполнения сверлильный станок (Рисунок 99).
Выполнение операции «Сверлить Контровка»
Запланируйте
задачу первоначально планируется на рабочего «П. Пет«Сверлить Контровка».
ров» в предпочитаемое время 11:00 (Рисунок 110),
так как «И. Иванов» в предпочитаемое время выполнения задачи занят, а «П. Петров» полностью
свободен.
«И. Иванов» недоступен некоторое время, а на «П.
Петрова» запланировано выполнение задачи
«Сверлить Контровка». Задача «Сделать Шестигранник» оценивает возможный конфликт при
размещении на ресурсах «И. Иванов» и «П. Петров» по Критерию минимального суммарного
времени пересечения с ранее запланированными
задачами. Таким образом, при размещении на рабочего «П. Петров» задачи «Сделать Шестигранник» в ее предпочитаемое время конфликт будет
минимальный. Следовательно, операция «Сделать
Шестигранник» планируется на рабочего «П. ПетЗапланируйте
задачу ров».
«Сделать Шестигранник». Операция «Сделать Шестигранник» имеет более
высокий приоритет, чем «Сверлить Контровка».
Поэтому «Сделать Шестигранник» просит подвинуться задачу «Сверлить Контровка». Но так как у
задачи «Сверлить Контровка» задано «Минимальное время начала», которое не дает возможности
подвинуться на более раннее время, то задача
«Сверлить Контровка» вынуждена уйти с ресурса
«П. Петров» и найти другой подходящий ресурс.
Таким ресурсом является «И. Иванов». Выполнение задачи «Сверлить Контровка» планируется на
сверлильный станок и на рабочего «И. Иванов» на
10:30 (Рисунок 111).
149
Рисунок 110 – Планирование задачи «Сверлить Контровка»
Рисунок 111 – Планирование задачи «Сделать шестигранник» с более высоким
приоритетом
6.6.4 Индивидуальные задания
1. Для задач «Изготовить скобу» и «Сделать гвоздь» требуется оборудование «Пресс». Задача «Сделать гвоздь» имеет приоритет 4, предпочитаемое
время – 10:00, минимальное время начала 10:30, максимальное время выполнения – 1 час. Задача «Изготовить скобу» имеет приоритет 2, предпочитаемое
время – 10:00, максимальное время выполнения – 2 часа. Создайте ресурсы
«И.Иванов» с разрядом 2, «П.Петров» с разрядом 2, пресс. Запланируйте выполнение задач «Сделать гвоздь» и «Изготовить скобу».
6.7 Сценарий планирования задач с проактивностью ресурса
6.7.1 Описание сценария
Сценарий «iteration_3/06_ResourceProactivity.script» демонстрирует возможность проактивного подбора задачи к ресурсу. Ресурс ищет подходящие
для себя заказы. Если для запрашиваемого заказа новый ресурс оказывается более подходящим, чем прежний, то производится переход заказа на новый ресурс.
6.7.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии производства, присутствующие в сцене, указаны ниже (Таблица 42).
Таблица 42 – Экземпляры концептов онтологии производства
150
Концепты онтологии
Ресурс
Задача
Экземпляры концептов
Оборудование:
­ Сверлильный станок
Задача:
­ Сверлить Контровка
Значения атрибутов экземпляров концептов приведены ниже (Таблица 43).
Таблица 43 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«Сверлить Контровка»
Значение атрибутов
­ Предпочитаемое время – 10:00
­ Максимальная длительность – 60 минут
6.7.3 Этапы проведения эксперимента
Действия
Загрузите
сценарий
«06_ResourceProactivity.script» из
папки data/scenarios/iteration_3/.
Введите в сцену рабочего «И.
Иванов». Задайте у созданного
рабочего разряд, равный 7.
Ожидаемый результат
Начальное расписание не должно содержать операций для всех ресурсов.
В сцену введен рабочий «И. Иванов» с разрядом 7.
Здача «Сверлить Контровка» планируется
Запланируйте задачу «Сверлить
на «И. Иванов» (Рисунок 112), так других
Контровка».
рабочих нет.
Введите в сцену рабочего «П.
В сцену введен рабочий «П. Петров» с разПетров». Задайте у созданного
рядом 5.
рабочего разряд, равный 5.
Ресурс «П. Петров» проактивно отправляет
запрос задаче «Сверлить Контровка». Задача оценивает категории рабочих. У «П.
Петрова» категория ниже, что позволит
разгрузить рабочего «И. Иванов» с потенНажмите на кнопку «Запустить циально более высокой оплатой. Задача сопроактивность».
глашается на предложение ресурса «П.
Петров» и переходит на него. Таким образом, ресурс «П. Петров» проактивно переманивает задачу «Сверлить Контровка»,
поскольку является более предпочтительным для данной задачи (Рисунок 113).
151
Рисунок 112 – Планирование задачи на ресурс «И.Иванов»
Рисунок 113 – Проактивный подбор задачи для ресурса «П.Петров»
6.7.4 Индивидуальные задания
1. Запланируйте выполнение задачи «Проточить, Нарезать резьбу, Отторцевать», предпочитаемое время – 11:00, максимальная длительность – 60 минут. В сцене имеются ресурсы «И. Иванов» с разрядом 5, «П. Петров» с разрядом 4 и «С. Сидоров» с разрядом 3. Запланируйте выполнение задачи.
2. Запланируйте выполнение задачи «Сделать шестигранник», предпочитаемое время – 10:00, максимальная длительность – 60 минут. В сцене имеются
ресурсы «И. Иванов» с разрядом 4, «П. Петров» с разрядом 2 и «С.Сидоров» с
разрядом 3. Запланируйте выполнение задачи.
6.8 Контрольные вопросы
1.
2.
3.
4.
5.
6.
Перечислите основные концепты онтологии производства.
Как задаются требования к ресурсам в онтологии?
Как отобразить последовательность операций в сложной задаче, содержащей подзадачи?
Как может повлиять недоступность ресурса на расписание выполнения операций в сложной задаче, содержащей подзадачи?
Каким образом приоритет задач, определенный в онтологии, влияет
на планирование расписания выполнения задач?
Каким образом агент ресурса проактивно подбирает задачи?
152
7 ЛАБОРАТОРНАЯ РАБОТА №3. ИЗУЧЕНИЕ ВИРТУАЛЬНОГО
РЫНКА В ЗАДАЧАХ АДАПТИВНОГО ПЛАНИРОВАНИЯ
ТЕХНОЛОГИЧЕСКОГО ПРОЦЕССА ПРОИЗВОДСТВА
7.1 Цели и задачи лабораторной работы
В мультиагентных системах законы микроэкономики, действующие на
виртуальном рынке, эффективно используются в задачах адаптивного планирования. В автоматизированной системе адаптивного планирования производства
реализованы также различные стратегии планирования событий и различные
критерии принятия решений.
Цель лабораторной работы № 3 – продемонстрировать, каким образом
возможности виртуального рынка используются при планировании технологического процесса производства.
В процессе выполнения лабораторной работы № 3 решаются следующие
задачи:
­ Изучение основных понятий виртуального рынка и микроэкономики.
­ Освоение приемов настройки алгоритмов планирования путем конфигурирования микроэкономики.
­ Изучение критериев принятия решений (главный, каскадный, свертка).
­ Изучение приемов визуализации опций.
­ Исследование влияния различных критериев на результат планирования.
­ Исследование изменения стратегии принятия решения в процессе планирования на результат планирования.
7.2 Модели микроэкономики
7.2.1 Расчет физической стоимости выполнения операций
В автоматизированной системе адаптивного планирования реализована
модель, на основе которой можно описать стоимость каждого ресурса, а также
вычислить физическую стоимость операций, необходимых для выполнения той
или иной задачи ( атрибут CostDescription). Стоимость ресурса включает в себя
себестоимость ресурса и ожидаемую прибыль от него. Расчет стоимости может
быть основан либо на параметрах заказа (OrderBased), либо на особенностях
использования самого ресурса (ResourceBased). Рассматривается два типа стоимости ресурсов и операций:
­ фиксированная стоимость, не зависящая от времени (FixedRate),
­ стоимость, зависящая от времени (TimeRate).
Тип TimeRate служит для описания стоимости ресурса в зависимости от
времени его использования. В частности, если стоимость определяется продолжительностью времени использования ресурса, в случае простоя ресурса стоимость не учитывается (тип DurationDependentRate). Напротив, тип DurationIndependentRate будет учитывать стоимость ресурса, независимо от того, использовался или не использовался ресурс в течение указанного периода времени.
153
Тип DurationIndependentRate не зависит от времени заказа, и является ResourceBased параметром. Тип DurationDependentRate зависит от времени заказа, и,
соответственно, является OrderBased параметром.
Поскольку амортизация – это стоимость износа, ее также можно описывать аналогично стоимости ресурсов. Если необходимо учитывать износ оборудования независимо от того, работало оно в течение определенного промежутка
времени или нет, следует использовать тип DurationIndependentRate. Если же
износ оборудования зависит от времени его работы, следует использовать тип
DurationDependentRate.
Стоимость использования ресурсов определяется в соответствии с двумя
схемами: суммирующая и максимальная.
В суммирующей схеме общая стоимость выполнения задачи на конкретном ресурсе определяется как сумма всех входящих стоимостей данного ресурса. В случае максимальной схемы выбираются максимально возможные расходы при использовании данного ресурса.
Для каждого ресурса можно рассчитать затраты, связанные с его использованием, т.е. себестоимость его использования. Расчет прибыли у ресурса зависит от выбора модели микроэкономики.
В том случае, если заказ может заказывать работу ресурсу и платить за
него по некоторому внутреннему тарифу, прибыль ресурса можно определить
как тариф на ресурс за вычетом себестоимости его использования. Тариф на ресурс хранится в атрибуте CostDescription самого ресурса в виде FixedRate, если
стоимость фиксированная, либо TimeRate, если стоимость зависит от времени,
а себестоимость – в виде атрибута Rate ресурса. Если заказ разделяет прибыль в
некотором регулируемом проценте на ресурсы, то этот процент можно хранить
в атрибуте Rate прибыли.
При этом все расчеты ведут агенты на основе сведений, извлеченных из
атрибутов CostDescription, и хранят информацию о процентах ресурсов, а также
операции по ним на своих счетах. Для просмотра счетов, можно использовать
Agent Log – лог агентских сообщений.
Задача изготовления зеркала состоит из четырѐх подзадач:
­ резка стекла,
­ изготовление рамы,
­ сборка зеркала,
­ установка зеркала.
Себестоимость выполнения заказа и ожидаемая прибыль от него будут
храниться в атрибутах CostDescription ресурсов. Стоимость задачи изготовления зеркала состоит из стоимостей входящих в нее подзадач. Прибыль от выполнения заказа будет распределяться по подзадачам в соответствии с некоторым внутренним тарифом. Внутри подзадач прибыль будут распределяться по
ресурсам.
Для изготовления зеркала потребуются следующие ресурсы:
­ Служебный персонал.
Расходы для каждого рабочего описываются с помощью DurationDepen154
dentRate, они зависят от категории рабочего, выполняющего данную операцию,
и определяются только спецификой ресурса(Resource Based).
­ Оборудование:
o
Станок для резки.
Стоимость определяется на основе суммирующей схемы. В нее входят
цена на электричество (тип DurationDependentRate) и износ станка (тип DurationIndependentRate):
Cost = Time*TimeCost + FixedCost, где
Time – время работы (возможно, простоя);
TimeCost – стоимость электричества + стоимость других необходимых
ресурсов (стоимость простоя, работы в холостом режиме);
FixedCost – фиксированные расходы, связанные с амортизацией оборудования.
o
Пресс.
Стоимость определяется на основе суммирующей схемы. В нее входят
цена на электричество (тип DurationDependentRate) и износ станка (тип DurationIndependentRate).
o
Станок для сборки.
Стоимость определяется на основе суммирующей схемы. В нее входят
цена на электричество (тип DurationDependentRate) и износ станка (тип DurationIndependentRate).
o
Инструменты для установки зеркала на автомобиль.
Расходы отсутствуют, поскольку данные инструменты имеются в большом количестве на складе.
­ Стекло.
Стоимость стекла фиксирована (тип FixedRate) и определяется спецификой заказа (тип OrderBased).
­ Брусок.
Стоимость бруска определяется фиксированными расходами (тип FixedRate) и самим заказом (тип OrderBased).
Полная стоимость изготовления зеркала вычисляется с использованием
суммирующей модели как сумма стоимостей всех ресурсов, необходимых для
выполнения данной задачи.
7.2.2 Модели логики принятия решений
План производства строится совместными усилиями агентов, которые в
ходе выполнения своих действий согласовывают свои решения друг с другом
на основе механизмов микроэкономики. Для каждого агента задается логика
принятия решений (Рисунок 114). В случае если логика принятия решений уникальна для данного агента, система позволяет задать настройки и индивидуально.
155
Рисунок 114 – Модель логики принятия решения
Логика принятия решений состоит из набора предпочтений для значений
критериев, каждое из которых содержит ссылки на критерий и соответствующую ему функцию – зависимость штрафа от значения критерия (Рисунок 115).
Данная функция может быть задана численно или аналитически; в самом простом случае она может быть определена в виде кусочно-линейной функции.
Чем больше значение штрафа, тем менее предпочитаемым является значение
критерия.
Рисунок 115 – Функция критерия принятия решения
В каждом из критериев задается объект-калькулятор, который может вычислить значение критерия исходя из сложившейся ситуации. Данный механизм позволяет добавлять новые критерии и при необходимости изменять методы их расчета. В настоящее время реализованы три критерия (Рисунок 116).
156
Рисунок 116 – Критерии принятия решений
Кроме предпочтений на критерии задается модель принятия решений, которая определяет, как именно учитывать критерии при оценке решений. Можно
выделить такие модели принятия решений (Рисунок 117):
­ метод главного критерия,
­ каскадный метод принятия решения,
­ свертка.
Рисунок 117 – Модели принятия решений
Согласно методу главного критерия, решение принимается по одному из
критериев, остальные критерии не рассматриваются.
Согласно модели каскадного критерия, сначала принимается решение по
первому критерию. Если значения данного критерия равны для нескольких ресурсов, рассматриваются вторые критерии в списке и т.д. Значение критерия
тем лучше, чем меньше значение функции штрафа.
Метод свертки использует веса критериев для определения комплексной
оценки по нескольким критериям.
7.3 Сценарий демонстрации микроэкономических характеристик
ресурсов
7.3.1 Описание сценария
Сценарий «iteration_4/02_Microeconomics.script» демонстрирует микроэкономические характеристики ресурсов (microeconomics).
7.3.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии производства, присутствующие в сцене, указаны ниже (Таблица 44).
Таблица 44 – Экземпляры концептов онтологии производства
Концепты онтологии
Ресурс
Задача
Экземпляры концептов
Участники:
­ Worker
Станок:
­ Pressing Machine
Задача:
­ Работа на станке («Make Frame»)
157
Значения атрибутов экземпляров концептов приведены ниже (Таблица 45).
Таблица 45 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«Make Frame»
Значение атрибутов
­ Предпочитаемое время – 8:00
­ Максимальная длительность – 4 часа
­ Необходимые ресурсы – Worker, Pressing
Machine
7.3.3 Этапы проведения эксперимента
Действия
Загрузите
сценарий
«02_Microeconomics.script»
из
папки data/scenarios/iteration_4/.
Запланируйте
Frame».
задачу
«Make
Отобразите расписание для всех
ресурсов, имеющихся в системе.
Ожидаемый результат
Начальное расписание не должно содержать операций для всех ресурсов. Задачи и
соответствующие события должны быть
загружены.
Появившаяся задача должна быть запланирована на 08:00 и не должна иметь временных конфликтов.
Расписание для Worker и Pressing Machine
должно включать операцию «Make Frame»
в 8:00. (Рисунок 118).
Поставьте галочку в поле «ПокаВ расписании появятся микроэкономичезать микроэкономику» (Рисунок
ские показатели (Рисунок 120).
119).
Появится вкладка, в которой будут указаны
В меню выберите Отчеты –>
микроэкономические показатели для соотМикроэкономика –> Задача.
ветствующей задачи (Рисунок 121).
Появится вкладка, в которой будут указаны
микроэкономические показатели для соответствующего ресурса (Рисунок 122) .
В меню выберите Отчеты –> В поле Prime cost указывается цена работы
Микроэкономика –> Ресурс.
на станке, в поле Payment указывается доход, полученный в результате работы станка, в поле Profit указывается прибыль в результате работы станка.
Появится вкладка, в которой будут указаны
В меню выберите Отчеты –>
микроэкономические показатели для соотМикроэкономика –> Операция.
ветствующей операции (Рисунок 123).
На вкладке Сцена –> Ресурс –>
Откроется вкладка таблицы Исполнитель
Исполнитель –> Исполнитель –>
(Рисунок 124).
двойной клик.
158
Нажмите на поле «Ценовое опиОткроется окно, в котором можно посмотсание рабочего» и выберите «Тареть оплату рабочего (Рисунок 125).
риф, зависящий от длительности».
Рисунок 118 – Расписание для всех ресурсов
Рисунок 119 – Включение микроэкономической информации
Рисунок 120 – Расписание для всех ресурсов с микроэкономическими
показателями
Рисунок 121 – Микроэкономические показатели для задач
Рисунок 122 – Микроэкономические показатели для ресурсов
Рисунок 123 – Микроэкономические показатели для операций
159
Рисунок 124 – Таблица «Исполнитель»
Рисунок 125 – Оплата рабочего
7.4 Сценарий демонстрации микроэкономических характеристик
взаимосвязанных ресурсов
7.4.1 Описание сценария
Сценарий «iteration_4/03_MicroeconomicsTwoOrders.script» демонстрирует микроэкономические характеристики ресурсов, связанных между собой.
7.4.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии производства, присутствующие в сцене, указаны ниже (Таблица 46).
Таблица 46 – Экземпляры концептов онтологии производства
Концепты онтологии
Ресурс
Задача
Экземпляры концептов
Участники:
­ Worker
Станок:
­ Pressing Machine
­ Glass Machine
Задача:
­ Работа на станке Pressing Machine («Make
Frame»)
­ Работа на станке Glass Machine («Cut
Glass»)
Значения атрибутов экземпляров концептов приведены ниже (Таблица 47).
Таблица 47 – Значения атрибутов экземпляров концептов
160
Экземпляр концепта
Задача
«Make Frame»
Задача
«Cut Glass»
­
­
­
­
­
­
Значение атрибутов
Предпочитаемое время – 8:00
Максимальная длительность – 4 часа
Необходимые ресурсы – Worker, Pressing
Machine
Предпочитаемое время – 14:00
Максимальная длительность – 2 часа
Необходимые ресурсы – Worker, Pressing
Machine, Glass Machine
7.4.3 Этапы проведения эксперимента
Действия
Ожидаемый результат
Начальное расписание не должно соЗагрузите
сценарий
держать операций для всех ресурсов.
«03_MicroeconomicsTwoOrders.script»
Задачи и соответствующие события
из папки data/scenarios/iteration_4/.
должны быть загружены.
Появившаяся задача должна быть запланирована на 08:00 и не должна
Запланируйте задачу «Make Frame».
иметь временных конфликтов. Ресурсы должны присутствовать на встрече
в 08:00 (Рисунок 126).
Появившаяся задача должна быть запланирована на 14:00 и не должна
Запланируйте задачу «Cut Glass».
иметь временных конфликтов. Ресурсы должны присутствовать на встрече
в 14:00 (Рисунок 127).
Рисунок 126 – Запланированная задача «Make Frame»
Рисунок 127 – Запланированная задача «Cut Glass»
161
На вкладке «Отчет по ресурсам» в поле «Время» можно варьировать промежутки времени, за которые мы будем просматривать экономические показатели. Если указать интервал времени с 8.00 до 12.00, т.е. в то время когда работа только Pressing Machine, можно заметить, что расходы на Glass Machine окажутся равными нулю (Рисунок 128).
Рисунок 128 – Экономические показатели в период времени с 8.00 до 12.00
Если указать интервал времени с14.00 до 16.00, т.е. в то время когда работала только Glass Machine, то можно видеть, что и в это время Pressing Machine также будет нести расходы (Рисунок 129), хотя она в это время не работала.
Рисунок 129 – Экономические показатели в период времени с 14.00 до 16.00
Это связано с тем, что у Pressing Machine есть амортизационные расходы
(Рисунок 130), поэтому даже когда она не используется, она все равно приносит
убыток, в отличие от Glass Machine (Рисунок 131).
Рисунок 130 – Зависимость экономических показателей Pressing Machine от
ресурсов
162
Рисунок 131 – Зависимость экономических показателей Glass Machine от
ресурсов
7.5 Сценарий планирования задачи «Изготовить зеркало заднего
вида»
7.5.1 Описание сценария
Сценарий «iteration_4/04_ModelMakeMirror.script» демонстрирует последовательность технологических операций задачи «Изготовить зеркало заднего
вида».
7.5.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии производства, присутствующие в сцене, указаны ниже (Таблица 48).
Таблица 48 – Экземпляры концептов онтологии производства
Концепты онтологии
Ресурс
Задача
Экземпляры концептов
Рабочие:
­ Bill
Станок:
­ Pressing Machine
­ Glass-Cutting Machine
­ Mirror Assembling Machine
­ Mirror Mounting Tools
Задача:
­ Работа на прессе – Pressing Machine
(«Make
Frame»)
­ Работа на станке для резки стекла – GlassCutting Machine («Cut Glass»)
­ Приклеивание стекла к корпусу («Mirror
Assembling»)
­ Монтирование зеркала к автомобилю («Mirror
Mounting»)
Значения атрибутов экземпляров концептов приведены ниже (Таблица 49).
Таблица 49 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
Значение атрибутов
­ Предпочитаемое время – 08:00
163
Экземпляр концепта
«Make Frame»
Задача
«Cut Glass»
­
­
­
­
­
Задача
«Mirror Assemnling»
­
­
­
Задача
«Mirror Mounting»
­
­
­
Значение атрибутов
Максимальная длительность – 4 часа
Необходимые ресурсы – Bill, Pressing Machine
Предпочитаемое время – 12:00
Максимальная длительность – 4 часа
Необходимые ресурсы – Bill, Glass-Cutting Machine
Предпочитаемое время – 16:00
Максимальная длительность – 4 часа
Необходимые ресурсы – Bill, Mirror Assembling
Machine
Предпочитаемое время – 20:00
Максимальная длительность – 4 часа
Необходимые ресурсы – Bill, Mirror Mounting
Tools
7.5.3 Этапы проведения эксперимента
Действия
Ожидаемый результат
Загрузите
сценарий
Начальное расписание не должно содержать
«04_ModelMakeMirror.script» из
операций для всех ресурсов.
папки data/scenarios/iteration_4/.
Последовательность операций для выполнения задачи «Изготовить зеркало заднего виЗапланируйте событие «Plan new да» определена в онтологии. Последоваtask» для задачи «Изготовить тельность операций можно видеть при вызеркало заднего вида».
боре пункта «Зависимости задач» в поле
«Выберите связи» (уровень детализации – 2)
для всей задачи в целом (Рисунок 132).
Расписание для рабочего Bill и Pressing Machine должно включать операцию «Make
Frame» в 08:00. Расписание для рабочего Bill
и Glass-Cutting Machine должно включать
операцию «Cut Glass» в 12:00. Расписание
Отобразите расписание для всех
для рабочего Bill и Mirror Assembling Maресурсов, имеющихся в системе.
chine должно включать операцию «Mirror
Assembling» в 16:00. Расписание для рабочего Bill и Mirror Mounting Tools должно
включать операцию «Mirror Mounting» в
20:00 (Рисунок 133).
164
Рисунок 132 – Последовательность операций для выполнения сложной задачи
«Изготовить зеркало заднего вида»
165
Рисунок 133 – Итоговое расписание для задачи «Изготовить зеркало заднего
вида»
7.5.4 Индивидуальные задания
1. Запланируйте выполнение задачи «Изготовить зеркало заднего вида»
так, чтобы операции «Сделать корпус» и «Вырезать стекло» выполнял рабочий
Bill, а операции «Приклеить стекло к корпусу» и «Монтировать зеркало к автомобилю» выполнял рабочий Bob. Длительность выполнения каждой операции 2
часа. Предпочитаемое время выполнения задачи «Изготовить зеркало заднего
вида» 18:00 часов.
2. Запланируйте выполнение задачи «Изготовить зеркало заднего вида»
так, чтобы операции «Сделать корпус» и «Вырезать стекло» выполнял рабочий
Bill, а операции «Приклеить стекло к корпусу» и «Монтировать зеркало к автомобилю» выполнял рабочий Bob. Длительность выполнения каждой операции 2
часа. Предпочитаемое время выполнения задачи «Изготовить зеркало заднего
вида» 18:00 часов. Рабочий Bob занят выполнением других операций с 13:00 до
15:00.
7.6 Сценарий планирования задачи «Изготовить изделие Болт-728»
7.6.1 Описание сценария
Сценарий «iteration_4/05_ModelMakeBolt.script» демонстрирует последовательность технологических операций задачи «Изготовить изделие Болт-728».
7.6.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии произ166
водства, присутствующие в сцене, указаны ниже (Таблица 50). Значения атрибутов экземпляров концептов приведены ниже Таблица 51.
Таблица 50 – Экземпляры концептов онтологии производства
Концепты онтологии
Ресурс
Задача
Экземпляры концептов
Рабочий:
­ Bill
Контролер:
­ John
Оборудование:
­ Mine Stove – печь шахтенная
­ Turret Lathe – станок револьверный
­ NC Machine – стнок с ЧПУ
­ Vertical Tuming Mill – вертикально-фрезерный
станок
­ Polishing Machine – кругло-шлифовальный станок
­ Drilling Machine – сверлильный станок
­ Workbench – верстак
­ Plating Bath – ванна гальваническая
­ Micrometer – микрометр
Задача:
­ Охлаждение
­ Торцевать, Точить, Отрезать
­ Проточить, Нарезать резьбу
­ Сделать шестигранник
­ Шлифовка
­ Сверлить, Контровка
­ Запилить, Снять заусенцы
­ Проверить на соответствие КД
­ Покрытие детали
­ Внешний осмотр, Контроль диаметра
Таблица 51 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«Охлаждение»
­
­
­
Задача
­
«Торцевать, Точить, Отрезать» ­
­
Задача
­
«Проточить, Нарезать резьбу» ­
­
Значение атрибутов
Предпочитаемое время – 01:00
Максимальная длительность – 2 часа
Необходимые ресурсы – Bill, Mine Stove
Предпочитаемое время – 03:00
Максимальная длительность – 3 часа
Необходимые ресурсы – Bill, Turret Lathe
Предпочитаемое время – 06:00
Максимальная длительность – 4 часа
Необходимые ресурсы – Bill, NC Machine
167
Экземпляр концепта
Задача
«Сделать шестигранник»
­
­
­
Задача
«Шлифовка»
­
­
­
Задача
«Сверить, Контровка»
­
­
­
Задача
«Запилить, Снять заусенцы»
­
­
­
­
­
­
­
­
­
­
­
­
Задача
«Проверить на соответствие
КД»
Задача
«Покрытие детали»
Задача
«Внешний осмотр, Контроль
диаметра»
Значение атрибутов
Предпочитаемое время – 10:00
Максимальная длительность – 2 часа
Необходимые ресурсы – Bill, Vertical Tuming Mill
Предпочитаемое время – 12:00
Максимальная длительность – 2 часа
Необходимые ресурсы – Bill, Polising Machine
Предпочитаемое время – 14:00
Максимальная длительность – 2 часа
Необходимые ресурсы – Bill, Drilling Machine
Предпочитаемое время – 16:00
Максимальная длительность – 2 часа
Необходимые ресурсы – Bill, Workbench
Предпочитаемое время – 18:00
Максимальная длительность – 2 часа
Необходимые ресурсы – John, Micrometer
Предпочитаемое время – 20:00
Максимальная длительность – 2 часа
Необходимые ресурсы – Bill, Plating Bath
Предпочитаемое время – 22:00
Максимальная длительность – 2 часа
Необходимые ресурсы – John, Micrometer
7.6.3 Этапы проведения эксперимента
Действия
Ожидаемый результат
Загрузите
сценарий
Начальное расписание не должно содер«05_ModelMakeBolt.script» из папжать операций для всех ресурсов.
ки data/scenarios/iteration_4/.
Последовательность операций для выполнения задачи «Изготовить изделие-728»
Запланируйте событие «Plan new определена в онтологии. Последовательtask» для задачи «Изготовить изде- ность операций можно видеть при выборе
лие Болт-728».
пункта «Зависимости задач» в поле «Выберите связи» (уровень детализации – 2)
для всей задачи в целом (Рисунок 134).
Расписание для рабочего Bill и соответствующего оборудования должно включать
Отобразите расписание для всех операцию «Охдаждение» в 01:00, операресурсов, имеющихся в системе.
цию «Торцевать, Точить, Отрезать» в
03:00, операцию «Проточить, Нарезать
резьбу» в 06:00, операцию «Сделать ше168
Действия
Ожидаемый результат
сигранник» в 10:00, операцию «Шлифовка» в 12:00, операцию «Сверлить, Контровка» в 14:00, операцию «Запилить,
Снять заусенцы» в 16:00, операцию «Покрытие детали» в 20:00. Расписание для
контролера John и Micrometer должно
включать операцию «Проверить на соответствие КД» в 18:00 и операцию «Внешний осмотр, Контроль диаметра» в 22:00
(Рисунок 135).
Рисунок 134 – Последовательность операций для выполнения сложной задачи
«Изготовить изделие Болт-728»
169
Рисунок 135 – Итоговое расписание для задачи «Изготовить изделие Болт-728»
7.6.4 Индивидуальные задания
1. Запланируйте выполнение задачи «Изготовить изделие Болт-728» так,
чтобы операции «Охлаждение», «Шлифовка» и «Покрытие детали» выполнял
рабочий Bill, а операции «Торцевать, Точить, Отрезать», «Проточить, Нарезать
резьбу», «Сделать шестигранник», «Сверлить, Контровка» и «Запилить, Снять
заусенцы» выполнял рабочий Bob. Длительность выполнения каждой операции
2 часа. Предпочитаемое время выполнения задачи «Изготовить изделие Болт728» 22:00 часов.
2. Запланируйте выполнение задачи «Изготовить изделие Болт-728» так,
чтобы операции «Охлаждение», «Шлифовка» и «Покрытие детали» выполнял
рабочий Bill, а операции «Торцевать, Точить, Отрезать», «Проточить, Нарезать
резьбу», «Сделать шестигранник», «Сверлить, Контровка» и «Запилить, Снять
заусенцы» выполнял рабочий Bob. Длительность выполнения каждой операции
2 часа. Предпочитаемое время выполнения задачи «Изготовить изделие Болт728» 22:00 часов. Рабочий Bob занят выполнением других операций с 07:00 до
09:00.
170
7.7 Сценарий демонстрации логики принятия решения при
выполнении задачи «Изготовить два изделия Болт-728»
7.7.1 Описание сценария
Сценарий «factory/06_MakeClamp2Resources.script» демонстрирует логику принятия решения при выполнении задачи «Изготовить два изделия Болт728». Для начала запланируем изготовление двух болтов, при условии недоступности одного из рабочих, а затем добавим в план операцию по изготовлению скобы и зададим логику принятия решений для планируемого заказа.
7.7.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии производства, присутствующие в сцене, указаны ниже (Таблица 52).
Таблица 52 – Экземпляры концептов онтологии производства
Концепты онтологии
Ресурс
Задача
Экземпляры концептов
Рабочий:
­ И.Сидоров
­ Н.Иванов
Контролер:
­ А.Кузнецова
Оборудование:
­ Mine Stove – печь шахтенная
­ Turret Lathe – станок револьверный
­ NC Machine – стнок с ЧПУ
­ Vertical Tuming Mill – вертикальнофрезерный станок
­ Polishing Machine – кругло-шлифовальный
станок
­ Drilling Machine – сверлильный станок
­ Workbench – верстак
­ Plating Bath – ванна гальваническая
­ Micrometer – микрометр
Задача:
­ Изготовить Болт 728 №1
­ Изготовить Болт 728 №2
­ Изготовить Скобу №1
Значения атрибутов экземпляров концептов приведены ниже (Таблица 53).
Таблица 53 – Значения атрибутов экземпляров концептов
171
Экземпляр концепта
Задача
«Изготовить Болт 728 N1»
Задача
«Изготовить Болт 728 N2»
Задача
«Изготовить Скобу N1»
Значение атрибутов
­ Предпочитаемое время – 29/11/06 00:00
­ Предпочитаемое время – 01/12/06 12:00
­ Предпочитаемое время – 28/11/06 12:00
7.7.3 Этапы проведения эксперимента
Действия
Загрузите сценарий «06_ MakeClamp2Resources.script» из папки
data/scenarios/factory/.
Запланируйте событие «Plan new
task» для задачи «Изготовить изделие Болт-728 №1».
Запланируйте событие «Resource
Unavailability» для рабочего И.
Сидоров.
Запланируйте событие «Plan new
task» для задачи «Изготовить изделие Болт-728 №2».
Задайте логику принятия решения
для планируемого заказа «Изготовить Скобу N1». Для этого необходимо выделить соответствующее этой задаче событие и в
пункте меню «Действия» выбрать
пункт «Редактировать модель
принятия решений у задачи…».
Затем выбрать модель главного
критерия и «PrefDeltaStartTime»
(«Предпочитаемое время») в качестве критерия (Рисунок 137).
Ожидаемый результат
Начальное расписание не должно содержать операций для всех ресурсов.
Результат планирования события показан
на Рисунок 136.
Событие «Resource Unavailability» для рабочего И. Сидоров запланировано (Рисунок
136).
В расписании появляются операции по изготовлению Болта 728 N2.
Так как у планируемого заказа в качестве
предпочитаемого времени указано время,
равное 28/11/06 12:00 (Рисунок 138), когда
наиболее подходящий рабочий (с соответствующим разрядом) недоступен, требуется добиться баланса интересов (trade off).
То есть в данном примере либо нарушить
сроки, либо выдать задание менее подходящему рабочему (например, с более высоким разрядом). Выбор решения зависит от
модели принятия решения, которая определяет, что для агентов важнее в данный момент времени – сохранение сроков выполнения заказа или более низкая стоимости
(за счет привлечения специалистов соответствующей квалификации).
В пункте меню «Действия» выбеЗаказ будет размещен на более дорогом рерите пункт «Запланировать заносурсе близко к предпочитаемому времени
во». Получите список вариантов
(Рисунок 139).
размещения, для чего в пункте
172
Действия
меню «Действия» выбрать пункт
«Показать опции».
Ожидаемый результат
Заказ при перепланировании переместится
и будет назначен рабочему с более низким
разрядом (Рисунок 140). Приведенный список вариантов размещения содержит опции, которые находятся ближе к предпочиВ качестве главного критерия таемому времени, чем опция, которая была
указажите «Rank» (разряд). В выбрана в данном случае. Это связано с
пункте меню «Действия» выбери- тем, что если выбран метод главного крите пункт «Запланировать заново». терия, то при принятии решения учитывается только разряд, а все опции по размещению имеют одну и ту же оценку. В данном случае агент заказа выбирает первую
встретившуюся опцию, отвечающую поставленным требованиям.
Установите метод каскадного
принятия решений. Укажите, что
При перепланировании заказа с учетом выопции необходимо сравнивать
бранной модели принятия решений, в качевначале по разряду, а в случае,
стве лучшей опции агент выбрал ближайесли разряды одинаковые, обрашую опцию к предпочитаемому времени,
щать внимание на менее приорипри условии выбора рабочего по критерию
тетные критерии – отклонение от
разряда (Рисунок 141).
предпочитаемого времени и общую загруженность ресурса.
173
Рисунок 136 – Планирование двух болтов и недоступности рабочего
174
а)
175
б)
Рисунок 137 – Задание в качестве модели принятия решений:
метод главного критерия (а) и предпочтения на критерий (б)
Рисунок 138 – Параметры планируемой задачи
а)
б)
176
Рисунок 139 – Заказ запланирован с учетом главного критерия –
минимальное отклонение (а). Список вариантов размещения (б)
а)
б)
Рисунок 140 – Заказ запланирован с учетом главного критерия – разряд (а).
Список вариантов размещения (б)
177
Рисунок 141 – Список вариантов размещения с использованием
каскадной модели принятия решений
7.8 Сценарий демонстрации распределения ресурсов с изменением
стратегии планирования при выполнении задачи «Изготовить два
зеркала заднего вида»
7.8.1 Описание сценария
Сценарий «MirrorLowThanHiTest.script» демонстрирует независимое изменение стратегии планирования различных заказов. В автоматизированной
системе адаптивного планирования реализованы две стратегии планирования:
­ Just in Time (JIT) – точно в срок,
­ As soon As Possible (ASAP) – как можно раньше.
Осуществляется планирование двух задач изготовления зеркала заднего
вида автомобиля, состоящих из нескольких подзадач. В начале обе задачи планируются с применением одной и той же стратегии. При этом один заказ, принятый от очень важного клиента, смещает в расписании второй заказ. В результате выполнение второго заказа начинает опаздывать. Но после изменения
стратегии планирования второй заказ снова выполняется в срок.
Если известно, хотя бы приблизительно, желаемое время окончания выполнения задачи, рекомендуется использовать стратегию JIT, так как задача будет стремиться завершить свое выполнение как можно ближе к этому значению
178
времени. Если желаемое время окончания выполнения задачи неизвестно, или
не удается удовлетворительно, т.е. без больших опозданий запланировать задачу по стратегии JIT, или необходимо выполнить задачу срочно в ближайшее
время, рекомендуется использовать стратегию ASAP.
7.8.2 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии производства, присутствующие в сцене, указаны ниже (Таблица 54).
Таблица 54 – Экземпляры концептов онтологии производства
Концепты онтологии
Ресурс
Задача
Экземпляры концептов
Рабочий:
­ Иванов
­ Петров
­ Николаев
­ Сидоров
Оборудование:
­ 2 пресса
­ 2 станка для резки стекла
­ станок для клейки стекла
­ инструмент для монтажа корпуса зеркала к
корпусу автомобиля
Задача:
­ Изготовить зеркало заднего вида №1
­ Изготовить зеркало заднего вида №2
Значения атрибутов экземпляров концептов приведены ниже (Таблица 55).
Таблица 55 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«Изготовить зеркало заднего
вида N1»
Задача
«Изготовить зеркало заднего
вида N2»
Значение атрибутов
­ Предпочитаемое время – 10/12/08 12:35
­ Обычный клиент
­ Предпочитаемое время – 10/12/08 12:30
­ VIP-клиент
­ Текущее время – 10/12/08 10:00
7.8.3 Этапы проведения эксперимента
Действия
Загрузите сценарий «MirrorLowThanHiTest»
из
папки
data/scenarios/mixed_strategy/.
Запланируйте задачу «Изготовить зеркало N1» к 12.35 (Выберите первое со-
Ожидаемый результат
Изначально расписание не должно содержать операций для ресурсов. В
очереди событий появятся 2 события.
Задача «Изготовить зеркало N1» планируется, при этом техоперации рас179
Действия
Ожидаемый результат
бытие в очереди событий, нажмите полагаются в расписании друг за друкнопку «Действие» → «Запустить гом. Задача планируется по стратегии
планирование события»).
JIT к 12.35 (Рисунок 142).
Задача «Изготовить зеркало N2» планируется по стратегии JIT к 12.30. Она
получена от важного клиента. Техоперации первой задачи (менее важной),
Запланируйте задачу «Изготовить зеркоторые были уже запланированы, пекало N2» к 12.30 (Выберите второе сореносятся на период с 10.45 до 12.50.
бытие в очереди событий, нажмите
В результате, первая задача уже не ускнопку «Действие» → «Запустить
певает запланироваться к 12.35. Факпланирование события»).
тическое время выполнения первой
задачи становится 12.50. Таким образом, мы получаем 15-минутное опоздание (Рисунок 143).
Измените стратегию планирования
менее важной задачи «Изготовить зеркало N1» и установите предпочитаемое время равным текущему времени:
­ выберите первое событие в очереди событий;
­ нажмите кнопку редактирования
В базе данных сохранятся новые парасобытия;
метры задачи (Рисунок 144).
­ сделайте двойной щелчок по
значению параметра «Задача»;
­ установите
предпочитаемое
время – 10/12/08 10:00;
­ выберите стратегию планирования подзадач – «Как можно быстрее».
Задача «Изготовить зеркало N1» плаПерепланируйте задачу «Изготовить
нируется по стратегии ASAP c 10.00
зеркало N1» (Выберите первое собыдо 11.50. Вторая задача в расписании
тие в очереди событий, нажмите кнопостается без изменений. Таким обраку «Действие» → «Запланировать зазом, обе задачи выполняются в срок
ново»).
(Рисунок 145).
180
Рисунок 142 – Планирование задачи «Изготовить зеркало N1» по стратегии JIT
Рисунок 143 – Планирование задачи «Изготовить зеркало N2» по стратегии JIT
181
Рисунок 144 – Изменение стратегии планирования и предпочитаемого времени
задачи
Рисунок 145 – Перепланирование задачи «Изготовить зеркало N1» по стратегии
ASAP
182
7.9 Сценарий планирования с изменением описания
технологического процесса в онтологии
7.9.1 Описание сценария
Данный сценарий демонстрирует возможность изменения описания технологических процессов с помощью изменения онтологии.
В онтологическое описание процесса изготовления изделия «Болт 728
N1» вносится новая технологическая операция. Для этого в xml-файл, описывающий онтологию производства, добавляются новые концепты, атрибуты и
отношения между ними. После этого производится планирование задачи, которая должна быть выполнена согласно модифицированному технологическому
процессу.
7.9.2 Минимальные требования для работы сценария
Для выполнения сценария необходимо выполнение следующих дополнительных условий:
­ Установленная JDK, версия которой выше 1.6.4.
­ В пути поиска программ для запуска (переменная PATH в ОС Windows)
прописать путь к папке bin, входящей в JDK. В ОС Windows XP это можно
сделать следующим образом:
 Открыть «Панель управления», выбрать значок «Система».
 В открывшемся окне выбрать закладку «Дополнительно», в ней нажать на
кнопку «Переменные среды».
 В нижней половине окна «Переменные среды» в секции «Системные переменные» выбрать строчку с переменной «PATH» и нажать в этой секции на кнопку «Изменить».
 В открывшемся окне в поле «Значение переменной» добавить путь к папке bin установленного JDK. Например, «C:\java\jdk1.6.0_04\bin», если JDK
установлен в папке «C:\java\jdk1.6.0_04\». Переменная «PATH» может содержать несколько путей, для разделения которых применяется специальный разделитель <;> (точка с запятой).
 Если в секции «Системные переменные» нет переменной «PATH», необходимо нажать на кнопку «Создать», в поле «Имя переменной» указать
«PATH»,
а
в
поле
«Значение
переменной»
указать
«C:\java\jdk1.6.0_04\bin» (или другой путь, если JDK был установлен в
другую папку).
­ Несколько раз подтвердить изменения нажатием кнопки <Ok>.
7.9.3 Начальное состояние сцены
Изначально расписание пустое. Экземпляры концептов онтологии
производства, присутствующие в сцене, указаны ниже (Таблица 56). Значения
атрибутов экземпляров концептов приведены ниже (
Таблица 57).
183
Таблица 56 – Экземпляры концептов онтологии производства
Концепты онтологии
Ресурс
Задача
Экземпляры концептов
Рабочий:
­ И. Сидоров
­ H. Иванов
Контролер:
­ А. Кузнецова
Оборудование:
­ Mine Stove – печь шахтенная
­ Turret Lathe – станок револьверный
­ NC Machine – станок с ЧПУ
­ Vertical Turning Mill – вертикальнофрезерный станок
­ Polishing Machine – кругло-шлифовальный
станок
­ Drilling Machine – сверлильный станок
­ Workbench – верстак
­ Plating Bath – ванна гальваническая
­ Micrometer – микрометр
Задача:
­ Изготовить Болт 728 N1
­ Изготовить Болт 728 N2
­ Изготовить Cкобу N1
Таблица 57 – Значения атрибутов экземпляров концептов
Экземпляр концепта
Задача
«Изготовить Болт 728 N1»
Задача
«Изготовить Болт 728 N2»
Задача
«Изготовить Скобу N1»
Значение атрибутов
Предпочитаемое время – 29/11/06 00:00
Предпочитаемое время – 01/12/06 12:00
Предпочитаемое время – 28/11/06 12:00
7.9.4 Этапы проведения эксперимента
Действия
Ожидаемый результат
В данном сценарии производится изменение онтологии. Чтобы новая онСкопируйте дистрибутив приложения
тология не повлияла на выполнение
во временную папку и запустите придругих сценариев, рекомендуется сделожение из нее.
лать копию дистрибутива и запускать
приложение из временной папки.
184
Действия
Загрузите сценарий «06_ MakeClamp2Resources.script» из папки data/scenarios/factory/.
Запланируйте задачу «Изготовить Болт
728 N1» (Выберите первое событие в
очереди событий, нажмите кнопку
«Действие» → «Запустить планирование события»).
Закройте приложение. С помощью
xml-редактора
откройте
файл
«data\FactoryOntology.xml». Если на
компьютере не установлен какой-либо
специализированный
xml-редактор,
можно воспользоваться редактором
WordPad, входящим в состав ОС
Windows, или другим текстовым редактором. Внесите указанные ниже
изменения
в
файл
«data\FactoryOntology.xml».
Добавьте описание нового типа ресурсов в соответствии с листингом 1.
(Выделенный код необходимо добавить в xml-файл).
Добавьте описание новой технологической операции в соответствии с листингом 2.
Укажите порядок выполнения новой
технологической операции в технологическом процессе в соответствии с
листингом 3.
Укажите, что новая технолгогическая
операция входит в технологический
процесс изготовления изделия «Болт
728 N1» в соответствии с листингом 4.
Ожидаемый результат
Изначально расписание не должно содержать операций для ресурсов.
Задача «Изготовить Болт 728 N1»
нируется, при этом техоперации
полагаются в расписании друг за другом. Задача планируется по стратегии
JIT (Рисунок 146).
Добавлено описание нового типа ресурсов «Инструменты для распаковки»
– «UnpackTools».
Добавлено описание новой технологической операции «Unpack» – «Распаковка».
Указано, что для задачи «Cool» предшествующей операцией, согласно новому технологическому процессу, является задача «Unpack».
Указано, что в технологический процесс по изготовлению изделия «Болт
728 N1» «MakeBolt728 N1» входит
технологическая операция «Unpack».
Производится компиляция xml-файла,
содержащего описание онтологии. ЕсЗапустите
командный
файл ли в логе сообщений указаны ошибки,
«build.cmd».
необходимо еще раз проверить корректность
файла
«data\FactoryOntology.xml».
!!! Для демонстрации данного сцена- Производится компиляция xml-файла,
рия подготовлена онтология «data\
содержащего описание онтологии.
185
Действия
Ожидаемый результат
FactoryOntology_ChangeOntDemo.xml»,
в которую уже внесены необходимые
дополнения. Чтобы ее использовать,
выполните следующие действия.
Удалите онтологию
«data\FactoryOntology.xml».
Переименуйте онтологию «data\
FactoryOntology_ChangeOntDemo.xml»
в
«data\FactoryOntology.xml».
Запустите
командный
файл
«build.cmd».
После успешной компиляции онтологии запустите приложение и загрузите
Расписание не должно содержать опесценарий
«06_
раций для ресурсов.
MakeClamp2Resources.script» из папки
data/scenarios/factory/.
В
описании
технологического
са перед всеми ранее описанными
Откройте вкладку «Ontology» и выбенологическими операциями должна
рите задачу «Изготовить болт 728».
появиться новая технологическая операция «Unpack» (Рисунок 147).
Задача «Изготовить Болт 728 N1» не
запланируется. Это связано с тем, что
после
обновления
онтологии
Запланируйте задачу «Изготовить Болт гический процесс «MakeBolt728 N1»
728 N1». (Выберите первое событие в стал содержать новую технологиочереди событий, нажмите кнопку ческую операцию, которой для
«Действие» → «Запустить планирова- нения требуются «Инструменты для
ние события»).
распаковки» – «UnpackTools». Однако
в сцене пока не создан ни один экземпляр инструментов «UnpackTools»
(Рисунок 148).
Откройте страницу редактирования В сцене появился один экземпляр
сцены. Выберите «Инструменты для сурса
«UnpackTools».
Теперь
распаковки» – «UnpackTools». Создай- гический процесс «Изготовить болт
те
один
экземпляр
ресурса 728 N1» может быть выполнен
«UnpackTools».
(Рисунок 149).
Перепланируйте задачу «Изготовить
Задача «Изготовить Болт 728 N1»
Болт 728 N1» (Выберите первое собынируется с учетом новой технологичетие в очереди событий, нажмите кнопской операции, которая отображается
ку «Действие» → «Запланировать зана диаграмме Гантта (Рисунок 150).
ново»).
186
Листинг 1
<concept name="Workbench" parent="Equipment"/>
<concept name="Micrometer" parent="Equipment"/>
<concept
name="PlatingBath"
userFriendlyName="Plating
Bath"
par-
ent="Equipment"/>
<concept name="Stand" parent="Equipment"/>
<concept name="UnpackTools" userFriendlyName="Unpack Tools" parent="Equipment"/>
<concept
name="CooledRod"
userFriendlyName="Cooled
Rod"
par-
ent="Component"/>
Листинг 2
<concept name="MeasuredRod" userFriendlyName="Rod After Control" parent="Component"/>
<concept
name="PlatedRod"
userFriendlyName="Plated
Rod"
par-
ent="Component"/>
<concept name="Bolt" userFriendlyName="Bolt" parent="Component"/>
<concept
name="Unpack"
userFriendlyName="Unpack"
par-
ent="FactoryComplexTask">
<attribute xsi:type="linkAttribute" valueConcept="Rod" name="Rod"
linkType="LINK"/>
<attribute
xsi:type="linkAttribute"
valueConcept="MakeBolt728"
name="MainTask" userFriendlyName="Main Task"
linkType="LINK_TO_OWNER" inverseFieldName="Unpack">
<tag name="MainTask"/>
187
</attribute>
<attribute xsi:type="floatAttribute" name="MaxDuration" userFriendlyName="Max Duration" defaultValue="2880"
compulsory="true">
<tag name="MaxDuration"/>
</attribute>
<attribute
xsi:type="linkAttribute"
valueCon-
cept="UnpackRodRequirements"
linkType="LINK"
name="TaskRequirements"
userFriendly-
Name="Requirements For Unpack Task"/>
</concept>
<concept
name="UnpackRodRequirements"
userFriendly-
Name="Requirements For Unpack Task" parent="TaskRequirements">
<attribute
xsi:type="linkAttribute"
valueCon-
cept="ToolsForUnpackRequirement"
linkType="LINK" name="Tools"
userFriendlyName="Requirement - Equipment For Unpack Task"/>
<attribute
xsi:type="linkAttribute"
valueCon-
cept="WorkerForUnpackRequirement"
linkType="LINK" name="WorkerRequirement"
userFriendlyName="Requirement - Worker For Unpack Task"/>
</concept>
<concept
name="ToolsForUnpackRequirement"
userFriendly-
Name="Requirement - Equipment For Unpack Task"
parent="EquipmentRequirement">
<attribute
xsi:type="linkAttribute"
valueConcept="UnpackTools"
188
name="UnpackTools"
userFriendlyName="Unpack tools"
linkType="LINK"/>
</concept>
<concept
name="WorkerForUnpackRequirement"
userFriendly-
Name="Requirement - Worker For Unpack Task"
parent="Requirement">
<attribute
xsi:type="linkAttribute"
valueConcept="Worker"
name="Worker" linkType="LINK"/>
<attribute xsi:type="longAttribute" name="Rank" defaultValue="5"/>
<attribute xsi:type="stringAttribute" name="RankComparator" defaultValue="more"
compulsory="true"/>
</concept>
<!-********************************************************************
********************* -→
<concept
name="Cool"
userFriendlyName="Cool"
par-
ent="FactoryComplexTask">
<attribute xsi:type="linkAttribute" valueConcept="Rod" name="Rod" linkType="LINK"/>
Листинг 3
<concept
name="Cool"
userFriendlyName="Cool"
par-
ent="FactoryComplexTask">
189
<attribute xsi:type="linkAttribute" valueConcept="Rod" name="Rod" linkType="LINK"/>
<attribute
xsi:type="linkAttribute"
valueConcept="Unpack"
name="RequiredUnpack"
userFriendlyName="Required Unpack Rod Task For Cool"
linkType="LINK">
<tag name="Predecessor"/>
</attribute>
<attribute
xsi:type="linkAttribute"
valueConcept="MakeBolt728"
name="MainTask" userFriendlyName="Main Task"
linkType="LINK_TO_OWNER" inverseFieldName="Cool">
<tag name="MainTask"/>
</attribute>
<attribute
xsi:type="floatAttribute"
name="MaxDuration"
userFriendly-
Name="Max Duration" defaultValue="2880"
compulsory="true">
<tag name="MaxDuration"/>
</attribute>
<attribute xsi:type="linkAttribute" valueConcept="CoolRodRequirements"
linkType="LINK"
name="TaskRequirements"
userFriendly-
Name="Requirements For Cool Task"/>
</concept>
Листинг 4
<concept name="MakeBolt728" userFriendlyName="Make Bolt 728" parent="MakeProduct">
190
<attribute xsi:type="linkAttribute" valueConcept="MakeScrewClampFromBolts"
name="MainTask1"
userFriendlyName="Main Task 1"
linkType="LINK_TO_OWNER" inverseFieldName="Bolt1">
<tag name="MainTask"/>
</attribute>
<attribute xsi:type="linkAttribute" valueConcept="MakeScrewClampFromBolts"
name="MainTask2"
userFriendlyName="Main Task 2"
linkType="LINK_TO_OWNER" inverseFieldName="Bolt2">
<tag name="MainTask"/>
</attribute>
<attribute
xsi:type="linkAttribute"
valueConcept="Unpack"
name="Unpack" linkType="PART_OF"
inverseFieldName="MainTask" cardinality="SINGLE">
<tag name="SubTask"/>
</attribute>
<attribute xsi:type="linkAttribute" valueConcept="Cool" name="Cool" linkType="PART_OF"
inverseFieldName="MainTask" cardinality="SINGLE">
<tag name="SubTask"/>
</attribute>
<attribute
xsi:type="linkAttribute"
valueConcept="TrimGrindCut"
name="TrimGrindCut"
userFriendlyName="Trim, Grind, Cut" linkType="PART_OF"
191
inverseFieldName="MainTask" cardinality="SINGLE">
<tag name="SubTask"/>
</attribute>
<attribute
xsi:type="linkAttribute"
valueConcept="TurnThreadFace"
name="TurnThreadFace"
userFriendlyName="Turn, Thread, Face" linkType="PART_OF"
inverseFieldName="MainTask" cardinality="SINGLE">
<tag name="SubTask"/>
</attribute>
Рисунок 146 – Планирование задачи «Изготовить Болт 728 N1»
192
Рисунок 147 – Новая онтология для задачи «Изготовить Болт 728 N1»
Рисунок 148 – Неудачное планирование задачи «Изготовить Болт 728 N1»
193
Рисунок 149 – Создание экземпляра «Unpack tools»
Рисунок 150 – Перепланирование задачи «Изготовить Болт 728 N1»
194
7.10 Контрольные вопросы
1.
2.
3.
4.
5.
6.
7.
8.
Какие типы стоимости ресурсов рассчитываются в автоматизированной системе адаптивного планирования?
Опишите модель расчета стоимости ресурсов.
Объясните порядок расчета стоимости ресурса на примере расчета
стоимости изготовления зеркала заднего вида автомобиля.
Какие модели логики принятия решений используются в системе?
Как задается модель логики принятия решений?
Какие стратегии приянятия решений реализованы в автоматизированной системе адаптивного планирования? В каких случаях следует
использовать каждую из них?
Какие микроэкономические показатели отображаются нпри работе?
Каким образом можно внести изменения в онтологию, описывающую технологический процесс производства?
195
ЗАКЛЮЧЕНИЕ
Адаптивное планирование производства в реальном времени на основе
мультиагентного подхода позволяет планировать сложные процессы с множеством зависимостей, поскольку мультиагентный подход обеспечивает следующие преимущества:
­ Обеспечение эффективного построения стратегических и тактических планов предприятия, которые удовлетворяют максимальному количеству требований, в условиях неопределенности и высокой динамики событий.
­ Интеграция системы интеллектуального планирования в единое информационное пространство предприятия в соответствии с современными международными и Российскими стандартами и требованиями по качеству производственного процесса.
­ Использование новейших технологий построения открытых систем, с обеспечением максимально возможной производительности и возможностью
удаленного доступа, в том числе через Интернет.
­ Простота интеграции с имеющимися системами поддержки жизненного
цикла изделия (PDM/PLM/CAD/CAM/CAE).
­ Распределенная архитектура, открытая к подключению новых цехов.
­ Высокая адаптивность и конфигурируемость системы при добавлении новых
знаний и расширении функциональности. Сокращение расходов на развитие
системы за счет использования онтологий.
­ Возможность быстрого создания системы на основе имеющихся заделов.
­ Сокращение сроков реализации бизнес-процессов предприятия и подготовки
полномасштабного внедрения, которые обеспечиваются современными методами накопления знаний в онтологиях.
­ Представление результата в наглядной форме, легко интерпретируемой операторами с возможностью формирования разнообразных отчетов.
­ Гибкое планирование производства в реальном времени на основе мультиагентного подхода позволяет планировать сложные процессы с множеством
зависимостей, поскольку мультиагентный подход обладает следующей фунциональностью:
 предполагает построение решений в ходе выявления и устранения конфликтов между элементами, что делает процесс поиска направленным и
быстро сужает пространство решений;
 позволяет находить «умные» решения, основанные на учете индивидуальных особенностей, ограничений и предпочтений каждого элемента
производства, а также на общих знаниях о технологических процессах,
возможностях оборудования и т.д.;
 является наиболее подходящим для адаптивного планирования, поскольку создаваемые расписания могут пересматриваться в любой момент времени в случае прихода новых событий;
 позволяет планировать производство весьма быстро, т.к. при приходе новых событий обычно требуется лишь частичный пересмотр созданных
196




ранее расписаний;
процесс планирования является направленным и строится от целей. Новый заказ пытается захватить интервал времени того ресурса, который
ему наилучшим образом подходит, а если этот ресурс занят, то пытается
договориться о его высвобождении. Распределение ресурсов происходит
примерно так, как это делают люди, но более эффективно, что заменяет
трудоемкий и механистический комбинаторный перебор вариантов;
процесс планирования базируется на асинхронном параллельном процессе взаимодействия множества агентов подобно тому, как взаимодействует
рой пчел или колония муравьев. Частично недетерминированный характер этого процесса, использующий сильные стороны метода проб и ошибок, защищает систему от попадания в локальные оптимумы и позволяет
ей постоянно находить все новые возможности для улучшения расписания;
решение в виде наилучшего возможного расписания ищется не предопределенным и последовательным образом, в результате работы жесткого
алгоритма, а исходя из сложившейся ситуации, и отталкиваясь от интересов наиболее занятых ресурсов, что предусмотреть и запрограммировать
заранее обычно невозможно или крайне трудоемко;
планированием легко управлять, а процесс построения расписаний легко
визуализировать и объяснить пользователю.
197
БИБЛИОГРАФИЧЕСКИЙ СПИСОК
1. Бесекерский В.А., Полов Е.II. Теория систем автоматического управления. Изд. 4-е, перераб. и доп. – СПб, Изд-во «Профессия», 2003. – 752 с. ISBN
5-93913-035-6, с. 17-18.
2. Трубицын А. На стыке экономики и технологии. PC WEEK/RE
№4/2005, с.25-27.
3. Bartholomew D. MES provides vital link. Industry Week, May, 2001. –
500p. ISSN: 00390895, p. 55.
4. John Phillips, «MES – How did we ever manage the business without it?».
5. Joseph A. Vinhais, «MES: The One-Stop Information Source», PIC.
6. http://www.mesa.org
7. http://www.mesa.ru/
8. Фобос. http://www.model.nn.ru/Fobos.htm
9. Фобос. http://www.mesa.ru/
10. Фобос. http://www.rtsoft.ru/
11. OMEGA PRODUCTION. http://www.omegasoftware.ru
12. YSB.Enterprise.Mes. http://www.orel.ru/~jsb
13. PolyPlan. Фролов Е. Б., Загидуллин Р. Р. Оперативно-календарное
планирование
и
диспетчирование
в
MES-системах.
http://www.mashportal.ru/solutions_manufacturing-10455.aspx.
14. Zenith SPPS. http://www.zspps.com
15. T-FACTORY 6. http://www.adastra.ru/products/overview/MES
16. Preactor. http://www.preactor.com/
17. Axapta
www.microsoft.com/Rus/Dynamics/Solutions/Axapta/Default.mspx
18. РТСофт. Интегрированная система технологической подготовки производства, оперативного календарного планирования и диспетчерского контроля
цеха
механообработки
ФОБОС.
http://www.mesa.ru/?p=3024,
http://www.asutp.ru/?p=400415
19. Гараева Ю. Р., Загидуллин Р. Р., Сун Кай Цинн. Российские MESсистемы или как вернуть производству оптимизм / // М., САПР и Графика.
2005. № 11, с. 20–24.
20. Кукареко Е., Молочко Д., Коровкин С. Модуль оперативнокалендарного планирования в системе Omega Production. «САПР и графика» 7'
2005. http://www.sapr.ru/Archive/SG/2005/7/16/
21. Основные
модули
системы
OMEGA
PRODUCTION.
http://www.omegasoftware.ru/downloads/omp_about.pdf
22. Новые
возможности
Zenith
SPPS
версии
1.8.
http://www.zspps.com/zen18.html
23. Официальный сайт. http://www.microsoft.com/project
24. Портал
сообщества
экспертов
по
Microsoft
Project.
http://www.microsoftproject.ru/
25. T-FACTORY MES – управление производством в реальном времени.
198
http://www.adastra.ru/products/overview/MES
26. Будник Р., Куминов В. MES-системы в дискретном производстве. PC
Week (412)46`2003. http://www.pcweek.ru/themes/detail.php?ID=66228
27. Агапов О. Причины неудач внедрения. http://erpnews.ru/doc274.html
28. Пономарев О.П. Наладка и эксплуатация средств автоматизации.
SCADA-системы. Промышленные шины и интерфейсы. Общие сведения о программируемых логических контроллерах и одноплатных компьютерах: Учебное
пособие / О.П.Пономарев; Ин-т «КВШУ».– Калининград: Изд-во Ин-та
«КВШУ», 2006, 80 с.
29. Фролов Е.Б., Загидуллин Р.Р. MES-системы. MES-системы, как они
есть или эволюция систем планирования производства. Часть II,
http://erpnews.ru/doc2593.html
30. Горшков А.Ф., Евтеев Б.В., Коршунов В.А. Титов В.А., Фролов Е.Б.
«Компьютерное моделирование менеджмента: Учебное пособие» // Под общ.
ред. Н.П. Тихомирова. – М.: Издательство «Экзамен», 2004.
31. Фролов Е.Б., Загидуллин Р.Р. MES-системы. Критерии, которые мы
выбираем. ERPNEWS, http://erpnews.ru/doc2690.html
32. Ногин В.Д. Принятие решений в многокритериальной среде: количественный подход. М.: ФИЗМАТЛИТ, 2002, 144 с.
33. Монден Я. "Тойота". Методы эффективного управления (Сокр. пер. с
англ.) –М.: Экономика, 1989.
34. Родников
А.Н.
Канбан,
система
Канбан
(Kanban).
http://www.ecsocman.edu.ru/db/msg/42591.html
35. Оперативное планирование в условиях низкой загрузки производства.
http://www.zspps.com/oper2.html
36. Поваров Г. К познанию научно-техн. прогресса // – М: «СИ», 1972.
37. http://ru.wikipedia.org/wiki/Сложная_система
38. Головкин Б.А. Расчет характеристик и планирование параллельных
вычислительных процессов. – М.: Радио и связь, 1983, 272 с.
39. 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.
40. 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.
41. S. Kirkpatrick and C. D. Gelatt and M. P. Vecchi, Optimization by Simulated Annealing, Science, Vol 220, Number 4598, pages 671-680, 1983.
42. Уссермен Ф. Нейрокомпьютерная техника. – М.: Мир, 1992.
43. Химмельблау Д. Прикладное нелинейное программирование. – М.:
Мир, 1975.
44. Аоки М. Введение в методы оптимизации. – М.:Наука, 1977.
45. Сальников А.Н. Cистема разработки и поддержки исполнения парал199
лельных программ// Диссертация на соискание учѐной степени кандидата физико-математических наук. Москва – 2006. УДК 519.682.3+519.687.1
46. Костенко В.А., Калашников А.В. Исследование различных модификаций алгоритмов имитации отжига для решения задачи построения многопроцессорных расписаний// Дискретные модели в теории управляющих систем.
Труды VII Международной конференции. М.: МАКС Пресс, 2006, с.179-184.
47. Goldberg D.E. Genetic Algorithms in Search Optimizations and Machine
Learning.-Addison.Wesly, 1989.
48. Вороновский Г.К., Махотило К.В., Петрашев С.Н., Сергеев С.А. Генетические алгоритмы, искусственные нейронные сети и проблемы виртуальной
реальности. – Харьков: Основа, 1997.
49. Сабанин В.Р., Смирнов Н.И, Репин А.И. Модифицированный генетический алгоритм для задач оптимизации в управлении. УДК 517.977.5.
50. Кофман А., Дебезей Г. Сетевые методы планирования и их применение. – М. Прогресс, 1968.
51. Богданов Д.В., Казанцев О.В. Программные методы и средства планирования и управления проектами. Информационные технологии №2(22), 1997.
52. Долгий Э. Теория для победителя.
http://citforum.fast.net.ua/SE/project/victor_theory/.
53. http://ru.wikipedia.org/wiki/Интеллектуальный агент.
54. Леонид Витальевич Канторович: человек и ученый. В 2 т. Редакторысоставители В. Л. Канторович, С. С. Кутателадзе, Я. И. Фет. – Новосибирск:
Изд-во СО РАН, Филиал «Гео», 2002, Т. 1.
55. Галеев Э.М., Тихомиров В.М. Оптимизация: теория, примеры, задачи,
2000.
56. Томас Х. Кормен и др. Глава 29. Линейное программирование // Алгоритмы: построение и анализ = INTRODUCTION TO ALGORITHMS. – 2-е
изд. – М.: «Вильямс», 2006.
57. Хемди А. Таха Глава 3. Симплекс-метод // Введение в исследование
операций = Operations Research: An Introduction. – 7-е изд. – М.: «Вильямс»,
2007, с. 95-141.
58. http://ru.wikipedia.org/wiki/Линейное_программирование.
59. Круглов В. В., Борисов В. В. Искусственные нейронные сети. Теория
и практика. – М.: Горячая линия – Телеком, 2001.
60. В. А. Терехов, Д. В. Ефимов, И. Ю. Тюкин. Нейросетевые системы
управления. – Высшая школа, 2002. – С. 184.
61. Роберт Каллан Основные концепции нейронных сетей = The Essence
of Neural Networks First Edition. – М.: «Вильямс», 2001.
62. 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.
63. Городецкий В.И., Грушинский М.С., Хабалов А.В. Многоагентные
системы (обзор) // Новости искусственного интеллекта, №2, 1998, с. 64-116.
200
64. Андреев М.В., Батищев С.В., Искварина Т.В., Минаков И.А. Система
планирования расписания выставок. // Труды VI Всероссийской научной конференции с международным участием «Новые информационные технологии.
Разработка и аспекты применения». Таганрог: ООО «Антон», 2003, с. 91-92.
65. Андреев М.В., Глащенко А.В., Иноземцев С.В., Киселев И.П., Сафронов А.В., Скобелев П.О. Логика динамической балансировки трейд-оффов
агентов в задачах построения связанных расписаний в транспортной логистике
реального времени. // Труды VIII-ой международной конференции «Проблемы
управления и моделирования в сложных системах». Самара: СНЦ РАН, 2006, с.
541-546.
66. 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.
67. 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.
68. Brooks, R. A., 1991, "Intelligence without Representation", Artificial Intelligence 47.
69. jade.tilab.com
70. vsis-www.informatik.uni-hamburg.de/projects/jadex/
71. 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.
72. Андреев В.В., Андреев М.В., Батищев С.В., Искварина М.В., Скобелев
П.О. Мультиагентный конструктор и планировщик транспортных сетей. // Труды VI-ой международной конференции «Проблемы управления и моделирования в сложных системах». Самара: СНЦ РАН, 2004, с. 254-259.
73. В. Андреев, К. Ивкушкин, И. Минаков, Г. Ржевский, А. Сафронов, П.
Скобелев. Основные компоненты внутреннего устройства мультиагентной системы. // Труды 5-ой Международной конференции по проблемам управления и
моделирования сложных систем, Самара, 17-21 июня 2003. – Самара: СНЦ
РАН, 2003, с. 304 - 316.
74. В. Андреев, C. Батищев, К. Ивкушкин, Т. Искварина, П. Скобелев Инструментальные средства для разработки мультиагентных систем промышленного масштаба// Труды 6-ой Международной конференции по проблемам
управления и моделирования сложных систем, Самара, 14-17 июня 2004. - Самара: СНЦ РАН, 2004, с. 233 - 240.
75. Андреев В.В., Андреев М.В., Батищева М.В., Олейников А.В., Скобелев П.О., Чевелѐв А.С. Конструкция агента в системах оперативного планирования и принятия решений. // Труды VII-ой международной конференции
«Проблемы управления и моделирования в сложных системах». Самара: СНЦ
РАН, 2005, с. 414-420.
201
Учебное издание
Андреев Михаил Владимирович
Иващенко Антон Владимирович
Симонова Елена Витальевна
Скобелев Петр Олегович
Царев Александр Вячеславович
Автоматизация адаптивного управления производством
на промышленном предприятии
Учебное пособие
Печатается в авторской редакции
Подписано в печать ____________. Формат 60х84 1/16
Бумага офсетная. Печать офсетная.
Усл. печ. л. ____. Усл. кр.-отт. ____. Уч.-изд. л. ____.
Тираж _______ экз. Заказ _______. Арт.С-_______/_____.
Поволжский государственный университет
телекоммуникаций и информатики
443010, г. Самара ул. Льва Толстого, 23
Издательство Поволжского государственного университета
телекоммуникаций и информатики
443010, г. Самара, ул. Льва Толстого, 23
202
Документ
Категория
Без категории
Просмотров
0
Размер файла
7 531 Кб
Теги
zare, adaptivno, avtomatizaziya, ivachenko, andreev, skobelev, simonova, upravlenie
1/--страниц
Пожаловаться на содержимое документа