Лабораторная работа №1. Изучение интерфейса программного средства имитационного моделирования ARENA и построение простейшей имитационной модели
МЕТОДЫ И СРЕДСТВА ИНФОРМАЦИОННЫХ ТЕХНОЛОГИЙ МОДЕЛИРОВАНИЯ ПРОИЗВОДСТВЕННЫХ ПРОЦЕССОВ
ПРАКТИКУМ
Содержание
Лабораторная работа №1. Изучение интерфейса программного средства имитационного моделирования ARENA и построение простейшей имитационной модели.. 3
Лабораторная работа №2. Построение модели с использованием блоков панели Basic Process программы имитационного моделирования ARENA... 21
Лабораторная работа №3. Организация вычислительного эксперимента и оценка его результатов средствами программного средства ARENA 26
Лабораторная работа 4. Построение модели с использованием блоков панели Advanced Process программного средства ARENA... 33
Приложение 1.. 38
Лабораторная работа №1. Изучение интерфейса программного средства имитационного моделирования ARENA и построение простейшей имитационной модели
Перед началом выполнения лабораторной работы требуется настроить интерфейс программы ARENA. Для этого:
· в пункте меню Object убрать флажок с позиции
AutoConnect
· выбрать пункт меню Tools/Optionsив диалоговом окне Options
o на вкладке Settings убрать флажок с пункта
Create Backup file when saving;
o на вкладке Edit Layers нажать кнопки Enable All и OK;
o на вкладке Run Layers нажать кнопки Enable All и OK;
o на вкладке Project Parameters установить все флажки в области Statistic Collection и нажать кнопку OK;
· выбрать пункт меню Run/Setupив диалоговом окне Run Setup
o на вкладке Project Parameters установить все флажки в области Statistic Collection и нажать кнопку OK.
В качестве примера рассмотрим процесс обработки поступающих документов менеджером. Методом Drag and Drop переместите в рабочую область три функциональных блока шаблона Basic Process: Create, Process и Dispose.
Пусть время между поступлением документов подчиняется нормальному закону распределения с математическим ожиданием 1 час и среднеквадратическим отклонением 6 мин или 0,1 часа. Время, которое необходимо менеджеру на отработку документа подчиняется треугольному распределению (распределению Симпсона) и имеет параметры: наиболее вероятное время – 2 часа, минимальное -1 час, максимальное – 3 часа.
Общий вид создаваемой модели, а также параметры функциональных блоков, показаны на рис.1.1.
Собственно это и есть вся модель. Перед началом имитации необходимо задать параметры запуска.
Пункт меню Run/Setup вызывает диалог установки параметров модели (рис.1.2).
Оставим пока без изменений значения, заданные по умолчанию.
Сохраните созданную модель (желательно в отдельной папке, т.к. при компиляции будут создаваться служебные файлы Arena).
Запустите модель, выбрав пункт меню Run/Go (или нажав F5, или соответствующей кнопкой на панели инструментов).
|
Рис. 1.2. Параметры запуска модели
Поскольку в поле Replication Length параметров запуска не указано время реализации модели (значение Infinite – не определено), имитация будет продолжаться до принудительного останова. Однако через некоторое время станет заметно, что очередь к блоку Doc Process неуклонно растет. Параметры работы менеджера не отвечают интенсивности поступления документов (рис.1.3).
 |
Рис. 1.3. Режим имитации
Добавим производительности ресурсу (включим в работу еще одного менеджера). Для этого остановите модель, щелкните на пиктограмме Resource и в поле Capacity введите значение 2. Запустив модель можно визуально убедиться, что количество документов, ожидающих обработки, колеблется примерно от 1 до 5.
Чтобы увидеть действительное текущее значение документов в очереди, необходимо анимировать соответствующую переменную. За анимацию общих объектов Arena отвечает панель Animate. Первоначально визуализируем текущее модельное время и дату. Для этого вызовем соответствующего мастера, щелкнув на кнопках Clock и Date панели Animate (рис.1.4).
 |
Рис. 1.4. Визуализация времени и даты
Затем вызовем диалог для анимации переменной, которая будет отражать текущее значение длины очереди (кнопка Variable панели Animate). Щелкнув правой клавишей мыши, вызовите построитель выражений (опция Build Expression) (рис.1.5).
В построителе выражений выберите пункт Basic Process Variables/Queue/Current Number In Queue, как показано на рис.1.6.
 |
Рис. 1.5. Вызов построителя выражений для расчета переменной
 |
Рис. 1.6. Редактор построителя выражений
Теперь отобразим в модели текущие время и дату. Для этого служат мастера, вызываемые соответствующими кнопками Clock и Date на панели Animate.
В заключение создадим график изменения числа отработанных документов. Для этого щелкните по кнопке Plot панели Animate. Для отображения графика воспользуемся стандартной переменной Arena, выбрав ее из списка поля Expression диалога Plot Expression, как показано на рис.1.7.
|
Рис. 1.7. Построение графика
В результате всех действий модель должна принять примерно такой вид, как показано на рис.1.8.
 |
Рис. 1.8. Анимация переменных модели
В разработанной модели присутствует ресурс, который на данный момент представляет собой двух менеджеров. Визуализируем работу ресурса. Воспользуемся той же панелью Animate. На ней присутствует кнопка Resource, которая открывает доступ к настройке анимации. Справа расположены картинки, которые можно поставить в соответствие определенному состоянию ресурса: Idle – свободен, Busy – занят, Inactive – неактивен (производительность 0), Failed – в состоянии сбоя. Библиотеки картинок можно менять, используя кнопку Open. Для примера воспользуемся картинками библиотеки Contact Center, как показано на рис.1.9.
Запустив модель можно наблюдать за сменой состояний ресурса (в данном случае используется только два состояния - свободен и занят).
Обратите внимание, что картинка относится ко всему ресурсу, а в действительности работают два менеджера. Поэтому в данном случае непонятно, как работает каждый менеджер.
Рис. 1.9. Визуализация состояний ресурса
Для устранения этого недостатка несколько преобразуем модель. В электронной таблице для объекта Resource исправьте имя Manager на Manager 1 и добавьте еще один ресурс Manager 2, в поле Capacity введите значение 1 в каждой строке. Теперь щелкните на объекте Set панели Project Bar и создайте набор, в который включите оба ресурса. Дважды щелкнув на блоке Doc Process, вызовите окно его свойств. Для поля Resources нажмите Edit. В появившемся окне Resources в поле Type выберите Set, а в поле Set name – Set 1. Результатом всех этих действий станет то, что вновь прибывший документ будет направляться к ресурсу из множества Set 1 по правилу Cyclical, т.е. последовательно проверяя, какой из ресурсов свободен.
Вызовите окно анимации ресурсов (кнопка Resource). Обратите внимание, что в поле Identifier теперь доступно два ресурса: Manager 1 и Manager 2. Определите анимацию для второго менеджера, не забыв изменить идентификатор для первого на Manager 1. В результате модель примет вид рис.1.10.
 |
Рис. 1.10. Анимация ресурсов
Для более адекватного моделирования рассматриваемого процесса необходимо учесть, что менеджеры не могут работать постоянно. У каждого из них может быть свой график работы. Спланируем их рабочее время.
Для этого воспользуемся объектом Schedule шаблона Basic Process. График работы первого менеджера показан на рис.1.11. На данном графике отражено, что менеджер работает с 8.00 до 17.00 с перерывом на обед с 13.00 до 14.00. График построен для одних астрономических суток. Для второго менеджера график будет аналогичным за исключением времени обеда – с 14.00 до 15.00.
Определив оба графика, назначим их ресурсам Manager 1 и Manager 2. Для этого в поле Type электронной таблицы Resource выберите Based on Schedule и задайте соответствующее имя графика (рис.12).
При назначении графиков ресурсам появляется их новое состояние – неактивен. Следует учесть его, добавив для каждого ресурса анимационную картинку для этого состояния дважды щелкнув на изображении ресурса.
Поскольку моделируемый период охватывает сутки, необходимо в поле Replication Length задать 24 часа (пункт меню Run/Setup). Таким образом будут смоделированы одни сутки. При этом заметьте, что интенсивность поступления документов остается одинаковой в течение всех суток.
 |
Рис. 1.11. График работы первого менеджера
 |
Рис. 1.12. Назначение графиков работы ресурсам
Для статистической оценки результатов моделирования, как отмечалось выше, необходима многократная реализация модели. При этом необходимо знать, как именно будет собираться статистика по всем повторениям (Replications). Для этого в диалоге Run Setup вкладки Replication Parameters есть группа переключателей Initialize Between Replications.
Как можно видеть, возможны четыре варианта:
Initialize Statistic (Yes) Initialize System (Yes). Выбор этого режима приведет к тому, что каждая реализация модели будет независимой. При каждом новом запуске модель будет стартовать с 0 и заканчиваться через 24 часа, а все собираемые статистики будут обнуляться. Результирующие параметры будут определяться как средние по всем реализациям.
Initialize Statistic (Yes) Initialize System (No). В этом режиме модель будет стартовать с 0 и заканчиваться через 24 часа в каждой реализации, а все собираемые статистики будут кумулятивными.
Initialize Statistic (No) Initialize System (Yes). В этом режиме модель будет стартовать с 0 и заканчиваться через 24*N часа, где N – число реализаций, но статистки для каждой новой реализации будут обнуляться.
Initialize Statistic (No) Initialize System (No). В этом режиме модель будет стартовать с 0 и заканчиваться через 24*N часа, где N – число реализаций, а все собираемые статистики будут кумулятивными.
Очевидно, что выбор того или иного режима определяется целями эксперимента, но со статистической точки зрения наиболее актуален первый режим, который задается по умолчанию.
Рассмотрим стоимостные характеристики модели.
В полях Busy/Hour и Idle/Hour электронной таблицы Resource для первого менеджера задайте 5 ед., а для второго – 6, что соответствует повременной оплате труда. Очевидно, что если каждый из менеджеров работает по 8 часов, то в день они должны зарабатывать 40 и 48 ед. соответственно. Однако запустите модель и по окончании имитации на вопрос Arena о просмотре результатов ответьте «Да». После этого Arena сгенерирует стандартные отчеты о результатах моделирования. В панели Project Bar (вкладка Reports) щелкните объект Resources. В группе значений Cost в поле Busy Cost цифры отличаются от 40 и 48. дело в том, что правило прекращения обслуживания по графику (Schedule Rule) для каждого менеджера установлено Ignore. Это означает, что менеджеры сначала заканчивают отработку документа, а затем делают перерыв. Соответственно, время перерыва сокращается. Следовательно, коэффициент использования графика будет больше единицы (поле Sched Util=1,33) (рис.1.13).
 |
Рис. 1.13. Расчет заработной платы
Измените правило Schedule Rule на Preempt для первого менеджера. В этом случае он будет уходить на обед точно в срок, даже если не закончил работу с документом. Результат этого изменения можно видеть на рис.1.14.
Поле Idle Cost в обоих случаях остается нулевым, т.к. оба менеджера заняты постоянно. Таким образом, заработная плата менеджера в день составит: Busy Cost + Idle Cost.
Можно ввести поощрительную надбавку за общее количество обработанных документов (поле Usage Cost отчета). Для этого измените значение поля Per Use электронной таблицы Resource, например, на 1. Тогда, Usage Cost = Num Seized * Per Use (рис.1.15). Если Per Use не равно 0, то значение Total Cost будет рассчитываться с учетом значения Usage Cost.
Рассмотрим назначение остальных разделов отчета. Для этого щелкните Category Overview на вкладке Reports панели Project Bar. На вкладке Preview генератора отчетов можно увидеть стандартный набор разделов, предлагаемых Arena (рис.1.16 – 1.22).
Рис. 1.14. Результат модификации Schedule Rule
Все приведенные ниже отчеты сгенерированы из предположения, что документы, прибывающие для обработки, «размещаются» в блоке Doc Process с параметром Value Added. При этом стоимость каждого обработанного документа определялась исключительно стоимостью затрат ресурсов, которые обрабатывали документы.
 |
Рис. 1.15. Вводный раздел
Полученные отчеты (все или часть из них) можно экспортировать практически во все известные форматы, использовав кнопку Export Report на панели инструментов генератора отчетов.
 |
|
|
Примечание. Total Cost может отличаться от VA Cost если в модели присутствуют блоки, в которых сущность размещается с параметром Value Added, но при этом не происходит задействование ресурсов
Рис. 1.17. Раздел Entity/Cost и Entity/Other
Рис. 1.18. Раздел Process
Рис. 1.19. Раздел Process (окончание)
Рис. 1.20. Раздел Queue
Рис. 1.21. Раздел Resource
Рис. 1.22. Раздел Resource (окончание)
В заключение рассмотрения примера, создадим несколько представлений модели. Когда модель отлажена и готова к эксплуатации, обычно «отделяют» логику модели от анимации. Иными словами, всю анимационную часть модели переносят на свободное место, чтобы усилить восприятие имитации.
Используя полосы прокрутки, переместитесь «вверх» рабочего пространства, чтобы оно было абсолютно пустым. Поскольку разработанная модель имитирует работу некоего офиса, с помощью любого графического редактора нарисуйте этот офис, как Вы себе это представляете. Можно воспользоваться готовым шаблоном. Например, в Visio 2003 существует шаблон Office Layout (рис.1.23).
 |
Рис. 1.23. Шаблон Visio 2003
Скопируйте его и через буфер обмена вставьте на свободное место в Arena.
Переместите на рисунок офиса изображения ресурсов, заменив их другими рисунками, т.к. офис показан сверху. Переместите сюда же очередь, переменные даты и текущего числа документов в очереди. В результате должен получиться примерно такой рисунок, как показано на рис.1.24.
Рис. 1.24. Изображение офиса
 |
Единственной доработки требует объект очередь. Дважды щелкнув по объекту, вызовите диалог настройки его свойств. В группе Type укажите Point. Затем щелкните по кнопке Points и, используя кнопку Add, добавьте несколько точек. Затем распределите точки, как показано на рис.25. Запустив модель, можно наблюдать работу офиса (рис.1.25).
Рис. 1.25. Имитация работы офиса
Теперь создадим хранимые представления для логической части модели и анимационной.
|
Рис. 1. 26. Создание хранимого представления
После создания представления его можно увидеть во вкладке Navigate панели Project Bar. Переместитесь в логическую часть модели и создайте представление для отображения логики модели.
Подводя итог, следует отметить, что все, о чем шла речь, касается всего лишь трех функциональных блоков, из которых построена модель. Даже поверхностный обзор возможностей Arena позволяет сделать вывод о фундаментальности и серьезной функциональности этого продукта. Логично было бы предположить, что другие функциональные блоки и шаблоны разработаны для моделирования более сложной логики процессов и облегчения создания их моделей.