close

Вход

Забыли?

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

код для вставкиСкачать
Федеральное агентство по образованию Российской Федерации
Волгоградский государственный технический университет
Кафедра «Системы автоматизированного проектирования
и поискового конструирования»
ПОСТРОЕНИЕ СТОХАСТИЧЕСКИХ ДИНАМИЧЕСКИХ
МОДЕЛЕЙ С ИСПОЛЬЗОВАНИЕМ СИСТЕМЫ ARENA 9.0
Методические указания
для выполнения контрольной работы
РПК
«Политехник»
Волгоград 2010
УДК 519.216.001.57:519.246.87
Построение
использованием
стохастических
системы
Arena
9.0.
динамических
Методические
моделей
с
указания
для
выполнения контрольной работы /Сост. Коробкин Д.М., Фоменков С.А.Волгоград: ВолгГТУ, 2010, 35 с.
В методических указаниях приводятся основы подхода к созданию
стохастических динамических моделей с использованием системы Arena
9.0. Излагаются методика выполнения работы.
Рис. 40, табл. 16, библиогр. – 3 назв.
Рецензент: доктор технических наук,
профессор кафедры САПРиПК
А.В. Заболеева-Зотова
Печатается по решению редакционно-издательского совета
Волгоградского государственного технического университета.
© Д.М. Коробкин, С.А. Фоменков, , 2010
© Волгоградский государственный
технический университет, 2010
2
Введение
Имитационное моделирование является мощным инструментом
исследования поведения реальных систем. Методы имитационного
моделирования позволяют собрать необходимую информацию о
поведении системы путем создания ее компьютерной модели. Эта
информация используется затем для проектирования системы.
С помощью имитационного моделирования можно ответить на
множество вопросов, возникающих в момент принятия решения об
изменениях в процессах, происходящих в бизнесе:
1) Как изменится рентабельность бизнеса?
2) Как проведенные изменения отразятся на производительности
технологического оборудования и персонала?
3) Какие дополнительные инвестиции потребуется сделать?
4) Каков срок окупаемости производимых инвестиций?
Очень часто эти вопросы остаются без ответов до тех пор, пока
предполагаемые изменения не будут осуществлены. Но после того как
изменения проделаны, цена исправления ошибочных решений становится
значительно выше. Имитационное моделирование дает возможность
тестировать разные идеи, «проигрывая» их на компьютерной модели, что
намного дешевле, чем проводить множество испытаний и исправлений
ошибок на реальных процессах.
Типичные примеры, где может быть с выгодой применено
имитационное моделирование:
1) Строительство
нового
производства
любой
отрасли:
машиностроение, металлургия, нефтехимическая промышленность,
деревообработка и др.
2) Расширение и модернизация существующего производства.
3) Постановка на производство новой продукции.
4) Проектирование системы транспортировки угля, руды из шахты
на поверхность и далее к потребителям.
5) Организация
логистической
системы,
состоящей
из
дистрибутивных центров, складов, транспортных средств.
6) Строительство транспортного узла.
7) Технико-экономическое
обоснование
внедрения
автоматизированных систем оперативным управлением производством,
складом, транспортным предприятием.
Одна из причин для того, чтобы использовать имитационное
моделирование – это повышение уровня автоматизации производства,
нацеленное на повышение производительности, качества продукции и на
снижение затрат, приведшее к увеличению сложности производственных
систем. А проблемы, возникающие в системах такой сложности, могут
быть проанализированы только с применением компьютерного
3
моделирования. Еще одна причина в том, что применение анимации в
моделировании
повысило
возможность
большего
понимания
имитационных моделей неспециалистами в моделировании, т.е.
руководителями, менеджерами и инженерами-производственниками.
Компьютерное моделирование включает в себя построение модели
отдельного агрегата, технологического процесса, всего производства в
целом,
логистической
системы
с
применением
такого
специализированного
программного
обеспечения,
как
система
имитационного моделирования Arena от компании Rockwell Software. Эта
модель будет полностью воспроизводить все процессы, происходящие в
реальности на производстве, складе, в любой логистической системе.
Используя модель, можно экспериментировать, проверять разные идеи для
понимания того, как реальная система будет вести себя в разных
ситуациях. Результаты имитации могут быть использованы при решении
оптимизационных задач в качестве оценки значений функциональных
характеристик моделируемой системы.
Программное обеспечение Arena, разработанное компанией Rockwell
Software (ранее Systems Modeling Corporation) создано для имитационного
моделирования, позволяет создавать подвижные компьютерные модели,
используя которые можно адекватно представить очень многие реальные
системы. Самая первая версия этой системы увидела свет в 1993 г. Arena
снабжена удобным объектно-ориентированным интерфейсом и обладает
расширенными возможностями по адаптации к всевозможным
предметным областям.
В основе ПО Arena лежит язык SIMAN. В результате моделирования
Arena 9.0 формирует отчеты, в которых можно посмотреть отчеты по:
1) объектам, находящимся в системе (общее время нахождения в
системе, суммарное время ожидания объекта в системе, количество
объектов, вошедших/вышедших в систему/из системы);
2) очередям, образующихся в модулях процессов, если ресурс
захвачен другим объектом (время ожидания обработки в очереди,
количество объектов, ожидающих в очереди);
3) процессам – статистика для каждого повторения;
4) ресурсам – статистика по затраченным ресурсам;
Если по результатам собранной статистики не устраивают какиелибо параметры, то изменение свойств модулей приведет к изменению
всех параметров. Т.е. методом прогона различных вариаций параметров
модели можно определить оптимальный вариант работы созданной
системы.
Создавать имитационные модели без предварительного анализа
бизнес-процессов не всегда представляется возможным. Действительно, не
поняв сути бизнес-процессов предприятия бессмысленно пытаться
оптимизировать конкретные технологические процессы. Поэтому
4
функциональные модели и имитационные модели не заменяют, а
дополняют друг друга, при этом они могут быть тесно взаимосвязаны.
Имитационная модель дает больше информации для анализа системы, в
свою очередь результаты такого анализа могут стать причиной
модификации модели процессов. Наиболее целесообразно сначала создать
функциональную модель, а затем на ее основе строить модель
имитационную. Для поддержки такой технологии инструментальное
средство функционального моделирования BPwin имеет возможность
преобразования диаграмм IDEF3 в имитационную модель Arena.
После запуска Arena автоматически открывается новый файл.
Модули помещаются на панель методом «drug & drop», соединяются с
помощью коннектора
. Если модуль остается выделенным, то при
помещении нового модуля на рабочую область (окно блок–схемы) эти
модули автоматически соединяются друг с другом.
Среда моделирования Arena представлена на рисунке 1.
Рисунок 1 – Среда моделирования Arena
Окно приложения разделено на три области:
1) Окно рабочего поля представляет графику модели, включая блоксхему процесса, анимацию и другие элементы
5
2) Окно свойств модулей служит для настройки параметров модели
таких как: время, издержки и другие параметры
3) Окно проекта
Окно проекта включает в себя несколько панелей:
1) Basic Process (панель основных процессов) – содержит модули,
которые используются для моделирования.
2) Reports (панель отчетов) – панель сообщений: содержит
сообщения,
которые
отображают
результаты
имитационного
моделирования.
3) Navigate (панель навигации) – панель управления позволяет
отображать все виды модели, включая управление через иерархические
подмодели.
Панель основных процессов содержит модули типа «Flowchart» (в
том числе Create, Dispose и Process), которые служат для отображения
потоков объектов и могут быть перенесены на рабочее пространство
модели, а также модули типа «Data» (например Queue), которые не могут
быть размещены в рабочее пространство модели и служат для настройки
параметров модели. Окно редактирования параметров появляется в
нижней части модели, когда фокус установлен на модуле типа «Data».
Имитационная модель включает следующие основные элементы:
источники и стоки (Create и Dispose), процессы (Process) и очереди
(Queue). Источники - это элементы, от которых в модель поступает
информация или объекты. Скорость поступления данных или объектов от
источника обычно задается статистической функцией. Сток - это
устройство для приема информации или объектов. Понятие очереди
близко к понятию хранилища данных - это место, где объекты ожидают
обработки. Времена обработки объектов (производительность) в разных
процессах могут быть разными. В результате перед некоторыми
процессами могут накапливаться объекты, ожидающие своей очереди.
Часто целью имитационного моделирования является минимизация
количества объектов в очередях. Тип очереди в имитационной модели
может быть конкретизирован. Очередь может быть похожа на стек пришедшие последними в очередь объекты первыми отправляются на
дальнейшую обработку (LIFO: last-in-first-out). Альтернативой стеку может
быть последовательная обработка, когда первыми на дальнейшую
обработку отправляются объекты, пришедшие первыми (FIFO: first-in-firstout). Могут быть заданы и более сложные алгоритмы обработки очереди.
Процессы - это аналог работ в функциональной модели. В имитационной
модели может быть задана производительность процессов.
1. Панель основных процессов
1.1. Графические модули
6
1.1.1. Модуль Create
Рисунок 2 – Модуль Create
Этот модуль является отправной точкой для сущностей в
имитационной модели. Сущности – это индивидуальные элементы,
обрабатываемые в системе. Создание сущностей модулем происходит по
расписанию, или же основываясь на значении времени между прибытиями
сущности в модель. Покидая модуль, сущности начинают обрабатываться
в системе. Тип создаваемых сущностей определяется в этом модуле.
Применение:
1) прибытие различных документов в сфере бизнеса (например:
заказы, чеки, документация);
2) прибытие клиентов в сфере обслуживания (например: в ресторан,
в магазин);
3) начало изготовления продукции на производственной линии.
Таблица 1.
Параметры модуля Create
Параметры Описание
Name
Уникальное имя модуля, которое будет отражено в блок
схеме
Entity Type
Название типа сущности, который будет создаваться
модулем
Type
Способ формирования потока прибытия. Type может иметь
значение
Random
(используется
экспоненциальное
распределение со средним значением, определенным
пользователем), Schedule (определяется модулем Schedule),
Constant
(будет
использоваться,
определенное
пользователем, постоянное значение; например, 100) или
Expression (поток прибытия будет формироваться по
определенному выражению)
Value
Определяет
среднее
значение
экспоненциального
распределения (Random) или постоянное значение времени
между прибытиями сущностей (если Type = Constant)
Schedule
Name
Имя расписания, которое определяет характер прибытия
сущности в систему
Expression
Этот параметр задает тип распределения или выражение,
определяющее время между прибытиями сущностей в
модель
7
Единицы измерения времени между прибытиями (день, час,
минута, секунда)
Units
Entities
arrival
per Количество сущностей входящих в систему за одно
прибытие
Max arrivals
Максимальное число сущностей, которое может создать
этот модуль
First Creation
Время, через которое прибудет первая сущность в модель от
начала симуляции
1.1.2. Модуль Process
Рисунок 3 – Модуль Process
Этот модуль является основным модулем процесса обработки в
имитационной модели. В модуле имеются опции использования ресурсов.
Кроме стандартного модуля Process, можно использовать подмодель,
придавая ей особую, определенную пользователем, иерархическую
логическую схему. В модуле можно также задавать добавочные
стоимостные и временные характеристики процесса обработки сущности.
Наиболее частое применение модуля Process:
1) проверка документов;
2) выполнение заказов;
3) обслуживание клиентов;
4) обработка деталей.
Таблица 2.
Параметры модуля Process
Параметр
Описание
ы
Name
Уникальное имя модуля, которое будет отражено в блок схеме
Type
Определяет логическую схему модуля. Standard означает, что
логическая схема находится внутри модуля и зависит от
параметра Action. Submodel показывает, что логическая схема
будет находиться ниже в иерархической модели. Подмодель
может содержать любое количество логических модулей
Action
Тип обработки происходящей внутри модуля. Delay просто
показывает, что процесс занимает какое- то время и не
отражает использование ресурсов. Seize Delay указывает на
8
то, что в этом модуле были размещены ресурсы и будет
происходить задержка, ресурсы будут захватываться (то есть
будут заняты обработкой сущности), и их освобождение будет
происходит позднее. Seize Delay Release указывает на то, что
ресурс(-ы) были захвачены, а затем через время освободились.
Delay Release означает, что ресурсы до этого были захвачены
сущностью, а в таком модуле сущность задержится и
освободит ресурс. Все эти параметры доступны только тогда,
когда Type = Standard
Priority
Значение приоритета модулей использующих один и тот же
ресурс где угодно в модели. Это свойство не доступно, если
Action = Delay или Delay Release, или когда Type = Submodel
Resources
Определяет ресурсы или группы ресурсов, которые будут
обрабатывать сущности в этом модуле (см. Ресурсы)
Delay Type
Тип распределения или процедура, определяющая параметры
задержки
Units
Единицы измерения времени задержки(день, час, минута,
секунда)
Allocation
Определяет стоимостные характеристики обработки. Value
Added - означает учитывать стоимостные характеристики, а
Non-Value Added не учитывать
Minimum
Поле,
определяющее
минимальное
значение
равномерного и треугольного распределения
для
Maximum
Поле,
определяющее
максимальное
значение
равномерного и треугольного распределения
для
Value
Поле, определяющее среднее значение для нормального и
треугольного распределения или значения для постоянной
временной задержки
Std Dev
Параметр, определяющий
нормального распределения
Expression
Поле, в котором задается выражение, определяющее значение
временной задержки, если Delay Type = Expression
1.1.3. Модуль Decide
9
стандартное
отклонение
для
Рисунок 4 – Модуль Decide
Этот модуль позволяет учитывать принятие решений в модели. Он
включает опции принятия решений основанных на условии By Condition
(например, если тип сущности Car) или основанных на вероятности By
Chance (например, 75% - true, а 25% - false). Условия могут быть основаны
на значении атрибута Attribute, значении переменной Variable, типе
сущности Entity Type или основанные на выражении Expression. Если
поставленное условие не выполняется то, сущности будут покидать
модуль через ветку False. Данный модуль позволяет выполнять проверку
не только одного условия, но и нескольких. Это достигается с помощью
свойства Type→N–way by Chance/by Condition. В зависимости от условия
сущность идет по нужной ветке.
Применение:
1) разделение дел на срочные дела и несрочные;
2) перенаправление недоделанных или сделанных неправильно
работ на доработку.
Таблица 3.
Параметры модуля Decide
Парамет
Описание
ры
Name
Уникальное имя модуля, которое будет отражено в блок схеме
Type
Тип принятия решения. By Chance - выбор направления
основывается на вероятности. By Condition – проверка на
выполнение условия
Percent
True
Значение, определяющее процент сущностей, который пойдут
по направлению True
If
Тип условия, которое будет проверяться на выполнение
Named
Имя переменной, атрибута или типа сущности, который будут
проверяться при входе сущности в модуль
Is
Математический знак условия, например, больше и т.д.
Value
Значение, с которым будет сравниваться атрибут или
переменная пришедшей сущности. Если тип условия –
Expression, то в выражении должен стоять знак условия,
например Color<> Red
1.1.4. Модуль Batch
10
Рисунок 5 – Модуль Batch
Этот модуль отвечает за механизм группировки в имитационной
модели. Группировка может быть постоянной или временной. Временно
сгруппированные комплекты позднее могут быть разъединены с помощью
модуля Separate. Комплекты могут состоять из любого числа входящих
сущностей, определенного пользователем или же сущности могут
объединяться в комплект в зависимости от атрибута сущности. Временные
и стоимостные характеристики выходящей сущности, представляющей
комплект будут равны сумме характеристик вошедших в группу
сущностей.
Сущности прибывают в модуль, становятся в очередь и остаются там
до тех пор, пока в модуле не будет набрано заданное количество
сущностей. Когда соберется нужное число сущностей создается сущность
представляющая комплект.
Применение:
1) собрать необходимое количество данных, прежде чем начинать
их обработку;
2) собрать ранее разделенные копии одной формы;
3) соединить пациента и его больничную карту приема к врачу.
Таблица 4.
Параметры модуля Batch
Парамет
Описание
ры
Name
Уникальное имя модуля, которое будет отражено в блок схеме
Type
Способ группировки сущностей, может быть Temporary
(временная), Permanent (постоянная)
Batch
Size
Число сущностей, образующих один комплект
Rule
Определяет, по какому признаку будут группироваться. Если
Rule = Any Entity, это значит что первые 3 (если Batch Size = 3)
сущности будут сгруппированы. Если Rule = By Attribute, то
объединяется заданное количество сущностей с определенным
атрибутом. Например, если Attribute Name = Color, то
сущности, имеющие значение атрибута Color, будут
сгруппированы
Attribute
Имя атрибута, по значению которого группируются сущности
11
Name
1.1.5. Модуль Separate
Рисунок 6 – Модуль Separate
Этот модуль может использоваться как для создания копий
входящих сущностей, так и для разделения ранее сгруппированных
сущностей. Правило для разделения стоимостных и временных
характеристик копий сущностей и разделенных сущностей определяется
пользователем. Когда временно сгруппированные сущности прибывают в
модуль, они раскладываются на составные сущности. Сущности покидают
модуль в той же последовательности, в которой они добавлялись в
комплект. Если модуль создает копии сущностей, то пользователь может
задать количество дубликатов сущности. У дублированной сущности
значения атрибута, а также анимационная картинка такие же, как и
оригинала. Оригинальная сущность также покидает модуль.
Применение:
1) разъединение ранее сгруппированных комплектов документов;
2) для параллельной обработки документов по одному заказу.
Таблица 5.
Параметры модуля Separate
Параметры
Описание
Name
Уникальное имя модуля, отраженное в блок схеме
# of Duplic
Количество создаваемых копий входящей сущности
Type
Способ разделение входящей в модуль сущности. Duplicate
Original – просто делает дубликаты входящей сущности.
Split Existing Batch требует чтобы входящая сущность была
предварительно временно сгруппирована
Cost
Duplicates
Разделение стоимостных и временных характеристик
входящей сущности между выходящими. Это значение
to определяется пользователем в процентах, т.е. сколько
процентов от стоимостных и временных характеристик
входящей сущности уйдет копиям (характеристики между
копиями делятся поровну)
12
Allocation
Rule
Метод разделения стоимости и времени, если выбран
Type=Split Existing Batch. Retain Original Entity Values –
сохраняет оригинальные значения сущностей. Take All
Representative Values – все сущности принимают
одинаковое значение. Take Specific Representative Values –
сущности принимают специфическое значение
1.1.6. Модуль Assign
Рисунок 7 – Модуль Assign
Этот модуль предназначен для задания нового значения переменной,
атрибуту сущности типу сущности, анимационной картинке сущности или
другой переменной в системе.
В одном модуле можно сделать только одно назначение.
Пример применения модуля Assign:
1) установление приоритета для клиентов;
2) присвоение номера вышедшему приказу.
Таблица 6.
Параметры модуля Assign
Параметры Описание
Name
Уникальное имя модуля, которое будет отражено в блок
схеме
Type
Тип назначения, которое будет осуществляться. Other может
включать в себя встроенные в Арену переменные, такие как
вместимость ресурса или конечное время симуляции
Variable
Name
Имя переменной, которая будет изменяться в этом модуле
Attribute
Name
Имя атрибута, который будет изменяться в этом модуле
Entity Type
Новый тип сущности, присваиваемый сущности в этом
модуле
Entity Picture
Новая анимационная картинка для сущности, прошедшей
этот модуль
Other
Имя переменной в системе, которая будет меняться
New Value
Присваиваемое новое значение для атрибута, переменной
1.1.7. Модуль Record
13
Рисунок 8 – Модуль Record
Этот модуль предназначен для сбора статистики в имитационной
модели. Модуль может собирать различные типы статистики, включая
время между выходами сущностей из модуля, статистику сущности (время
цикла, стоимость), статистику за период времени (период времени от
заданной точки до текущего момента). Также доступен количественный
тип статистики.
Частое применение модуля:
1) подсчитать, какое количество заказов было выполнено с
опозданием;
2) подсчитать количество работы, совершаемое за один час.
Таблица 7.
Параметры Модуль Record
Парамет
Описание
ры
Name
Уникальное имя модуля, которое будет отражено в блок схеме
Type
Определяет тип статистики, которая будет собираться. Count –
будет увеличивать или уменьшать статистику на заданное
значение. Entity Statistics будет собирать общую статистику о
сущности, например, время цикла, стоимостные характеристики
и т. д. Time Interval будет считать разницу между значением
атрибута и текущим временем моделирования. Time Between
будет отслеживать время между вхождением сущностей в
модуль. Expression будет просто фиксировать значение
определяемое выражением
Attribute
Name
Имя атрибута, значение которого будет использоваться для
интервальной статистики
Value
Значение, которое будет добавляться к статистике, когда в
модуль будет прибывать сущность
1.1.8. Модуль Dispose
Рисунок 9 – Модуль Dispose
14
Этот модуль является выходной точкой из имитационной модели.
Статистика о сущности может собираться до того момента пока она не
выйдет из системы.
Применение:
1) Окончание бизнес процесса;
2) Клиенты покидают отдел.
Таблица 8.
Параметры модуля Dispose
Параметры
Описание
Name
Уникальное имя модуля, отраженное в блок схеме
Record Entity Определяет, будет ли вестись статистика о выходе
Statistics
сущности из системы
1.2. Модули данных
1.2.1. Модуль Entity
Рисунок 10 – Модуль Entity
Этот модуль определяет тип сущности и ее анимационную картинку
в имитационном процессе, также определяет стоимостную информацию.
Для каждого источника должен быть определен тип сущности,
который он генерирует.
Применение модуля Entity:
1) Документы: факсы, письма, отчеты и т. д.;
2) Люди в моделях больницы или магазина.
Таблица 9.
Параметры модуля Entity
Параметры
Описание
Entity Type
Название типа сущности
Графическое
представление
сущности
в
начале
имитационного процесса. Это значение может быть
Initial Picture впоследствии изменено с помощью модуля Assign.
Просмотреть анимационные картинки можно так: Edit/
Entity picture
Holding
Cost/Hour
Initial
Почасовая стоимость обработки сущности в системе. Эта
стоимость учитывается, когда сущность находится в
системе, либо в очереди, либо в стадии обработки
VA Значение, присваиваемое атрибуту сущности «добавочная
15
стоимость». Значение атрибута будет увеличиваться
каждый раз, как только сущность будет обрабатываться
процессом с добавочной стоимостью
Cost
Значение, присваиваемое атрибуту сущности «не
NVA добавочная стоимость». Значение атрибута будет
увеличиваться каждый раз, как только сущность будет
обрабатываться процессом с не добавочной стоимостью
Initial
Cost
1.2.2. Модуль Queue
Этот модуль данных предназначен для изменения правила
расстановки сущностей в очереди. По умолчанию тип очереди First in First
out.
Применение:
1) Стопка документов, ожидающих освобождения ресурса;
2) Место
для
собирания
частей
ожидающих
упаковки
(группировки).
Таблица 10.
Параметры модуля Queue
Параметры Описание
Name
Уникальное имя модуля, которое будет отражено в блок
схеме
Attribute
Name
Имя атрибута, значение которого будет учитываться, если
тип = Lowest Attribute Value или Highest Attribute Value
Type
Правило расстановки сущностей в очереди. First in First out –
первый вошел, первый вышел. Last in first out – последний
пришел, первый вышел. Lowest Attribute Value – первый
выйдет из очереди тот, значение атрибута у которого
низшее. Highest Attribute Value – первый выйдет из очереди
тот, значение атрибута у которого наивысшее
1.2.3. Модуль Resource
Рисунок 11 – Модуль Resource
Этот модуль предназначен для определения ресурсов и их свойств в
имитационном процессе, кроме того, модуль включает в себя стоимостную
информации о ресурсах и вместимость ресурсов. Ресурсы могут иметь
16
фиксированную вместимость или же основанную на расписании. У
ресурсов с фиксированной вместимостью в течение имитационного
процесса вместимость изменяться не может.
Применение:
1) Люди (клерки, продавцы, бухгалтеры, рабочие и т. д.);
2) Оборудование (телефонная линия, станок, компьютер).
Таблица 11.
Параметры модуля Resource
Параметры Описание
Name
Имя ресурса
Type
Метод, определяющий вместимость ресурса. Fixed Capacity
– фиксированная вместимость ресурса. Based on Schedule –
вместимость ресурса определяется модулем Schedule
Capacity
Число ресурсов, находящихся в системе
Schedule
Name
Имя Schedule модуля, который определяет вместимость
ресурса, если Type = Based on Schedule
Busy / Hour
Почасовая стоимость обработки сущности ресурсом. Время
учитывается только тогда, когда ресурс занят обработкой и
прекращает учитываться, когда ресурс освобождается
Idle / Hour
Стоимость ресурса, когда он не занят
Per Use
Стоимость обработки ресурсом одной сущности (не зависит
от времени)
1.2.4. Модуль Schedule
Рисунок 12 – Модуль Schedule
Этот модуль может использоваться вместе с модулем Resource для
определения вместимости ресурса. Также модуль используется вместе с
модулем Create для задания расписания прибытия сущностей.
Применение:
1) Расписание работы персонала с перерывами на обед;
2) Значение покупателей прибывающих в супермаркет.
Таблица 12.
Параметры модуля Schedule
Параметры Описание
Name
Название расписания
17
Type
Тип расписания, который может быть Capacity (расписание
для ресурсов), Arrival (для модуля Create) или Other
(разнообразные временные задержки или факторы)
Time Units
Масштаб оси времени в графике расписания
1.2.5. Модуль Set
Этот модуль данных, который описывает группу ресурсов,
использующихся в модуле Process. В группе могут находиться несколько
ресурсов. Модуль set автоматически создает ресурсы, вместимость
которых по умолчанию равна 1 и без всякой стоимостной информации.
Следовательно, если для ресурсов входящих в группу не нужно
стоимостной информации и вместимость более 1, то можно обойтись
созданием только модуля Set.
Возможно применение модуля для организации работы группы
работников, например, по очереди.
Таблица 13.
Параметры модуля Set
Параметры
Описание
Name
Название группы
Members
Перечисляет ресурсы, входящие в группу. Порядок
перечисления ресурсов важен, когда в модуле Process
используется правило выбора Cyclical или Preferred
Order
Resource Name
Названия ресурсов входящих в группу
1.2.6. Модуль Variable
Этот модуль данных определяет значение переменной. Переменные,
относящиеся к модулю Decide или Assign, могут использоваться в
выражениях. Если переменная не описана в этом модуле, то ее значение
равно 0.
Применение:
1) Число документов обрабатываемых в час;
2) Присвоение серийного номера для идентификации продукции.
Таблица 14.
Параметры модуля Variable
Параметры Описание
Name
Имя переменной
Initial Value
Первоначальное значение переменной. Это значение в
последствии может меняться модулем Assign
18
Rows
Число строк в размерной переменной
Columns
Число столбцов в размерной переменной
Определяет время, когда значение переменной сбрасывается
в
начальное
значение.
Statistics – сбрасывает переменную в начальное значение в
любой момент, когда статистика была расчищена.
Clear Option
System – сбрасывает переменную в начальное значение в
любой
момент,
когда
система
была
расчищена.
None – никогда не сбрасывает переменную в начальное
значение, исключая предшествующую первой репликации
Statistics
Определяет, будет ли вестись статистика по этой переменной
19
2. Панель отчетов
С помощью панели отчетов можно просмотреть результаты
проигрывания имитационной модели. На панели отчетов представлены
несколько видов отчетов. Отчет Category Overview (краткий обзор
категорий) отражает итоговую информацию о сущностях, процессах,
очередях и ресурсах. Также показывает информацию о заданных
пользователем переменных и информацию, собранную модулем Record.
2.1. Отчет о сущностях
Отчет о сущностях разделен на несколько частей.
Cycle Time: в этой части отчета показано среднее, максимальное и
минимальное время существования сущности. Время существования
сущности считается с момента её прибытия в систему и до того момента,
когда сущность попадает в модуль Dispose. Ниже представляется
гистограмма среднего времени цикла для каждого типа сущности.
NVA Cost: в этой части показано среднее, максимальное и
минимальное значение не добавочной стоимости сущностей по каждому
типу сущностей. Не добавочная стоимость рассчитывается на основании
значения NVA Time.
Total Cost: в этой части показано среднее, максимальное и
минимальное значение общей стоимости сущностей по каждому типу
сущностей. Общая стоимость вычисляется путем сложения стоимости
ожидания, добавочной стоимости и не добавочной стоимости для каждой
сущности. Ниже представляется сравнительные гистограммы средних
значений общей стоимости сущности для каждого типа сущности.
VA Cost: в этой части показано среднее, максимальное и
минимальное значение добавочной стоимости сущностей по каждому типу
сущностей. Добавочная стоимость рассчитывается на основании VA Time.
Wait Cost: в этой части показано среднее, максимальное и
минимальное значение стоимости ожидания сущностей по каждому типу
сущностей. Стоимость ожидания подсчитывается исходя из времени
ожидания, стоимости ресурса и стоимостью нахождения сущности в
системе.
Wait Time: в этой части показано среднее, максимальное и
минимальное значение времени ожидания сущностей по каждому типу
сущностей. Время ожидания – это период времени с момента поступления
сущности в очередь (либо в модуле Process ожидает ресурс, либо в модуле
Batch ожидает группировки) и до момента выхода из нее (начнет
обрабатываться, либо будет сгруппирована).
WIP (Work In Process): в этой части показано среднее, максимальное
и минимальное значение времени ожидания сущностей по каждому типу
сущностей.
20
2.2. Отчет о процессах
Отчет о процессах разделен на несколько частей.
Cycle Time: в этой части отчета показано среднее, максимальное и
минимальное время цикла процесса. Время цикла процесса считается с
момента прибытия в модуль Process и до того момента, когда сущность
покидает модуль. В разделе представляется гистограмма среднего времени
цикла для каждого процесса.
NVA Cost: в этой части показано среднее, максимальное и
минимальное значение недобавочной стоимости сущностей по процессу.
Не добавочная стоимость рассчитывается на основании NVA Time.
Total Cost: в этой части показано среднее, максимальное и
минимальное значение общей стоимости сущностей по процессу. Общая
стоимость вычисляется путем сложения стоимости ожидания, добавочной
стоимости и не добавочной стоимости для каждой сущности. В разделе
представляется сравнительные гистограммы средних значений общей
стоимости сущности для каждого типа сущности.
VA Cost: в этой части показано среднее, максимальное и
минимальное значение добавочной стоимости сущностей по каждому типу
сущностей. Добавочная стоимость рассчитывается на основании VA Time.
Wait Cost: в этой части показано среднее, максимальное и
минимальное значение стоимости ожидания сущностей по каждому типу
сущностей. Стоимость ожидания подсчитывается исходя из времени
ожидания, стоимости ресурса и стоимостью нахождения сущности в
системе.
Wait Time: в этой части показано среднее, максимальное и
минимальное значение времени ожидания сущностей по каждому типу
сущностей. Время ожидания – это период времени с момента поступления
сущности в очередь (либо в модуле Process ожидает ресурс, либо в модуле
Batch ожидает группировки) и до момента выхода из нее (начнет
обрабатываться, либо будет сгруппирована).
WIP: в этой части показано среднее, максимальное и минимальное
значение времени ожидания сущностей по каждому типу сущностей.
2.3 Отчет о ресурсах
Utilization определяется по величине уровня использования
(например, такой, как Number Busy / Number Scheduled (Количество
занятых / Количество запланированных)) в каждый момент времени с
последующим вычислением средне-взвешенного по времени. Такая
практика наиболее подходит при анализе минимальных и максимальных
значений или при отслеживании уровня использования по времени
(например, с помощью графика). Но к среднему значению подобной
статистики необходимо относиться достаточно осторожно.
21
Scheduled Utilization вычисляется с помощью деления среднего
количества занятых на среднее количество запланированных, с
формированием одиночного статистического показателя. Это наиболее
подходит в случае работы с одиночным кумулятивным показателем уровня
использования, в частности, если количество запланированных меняется
со временем. Но так как в данном случае мы имеем дело с кумулятивной
статистикой,
промежуточные
наблюдения
для
количества
запланированных отсутствуют.
3. Панель навигации
С помощью панели навигации можно быстро передвигаться по
различным уровням модели, быстро менять виды. Можно задать быстрые
клавиши для изменения вида. Виды подмоделей создаются автоматически,
но также возможно добавить новые виды с помощью команды Named
Views  Add. Можно передвигаться не только по различным уровням
модели, но также быстро получать нужный масштаб какой – либо части
модели.
ПОСТРОЕНИЕ СТОХАСТИЧЕСКИХ ДИНАМИЧЕСКИХ МОДЕЛЕЙ С
ИСПОЛЬЗОВАНИЕМ СИСТЕМЫ ARENA 9.0
ПОРЯДОК ПРОВЕДЕНИЯ РАБОТЫ
1) Получить задание на имитационное моделирование.
2) Разработать имитационную модель.
3) Занести в отчет разработанную имитационную модель и
проведенные на ней расчеты.
4. Пример модели, созданной в ARENA 9.0
«Моделирование работы центра страхования автогражданской
ответственности»
4.1. Сбор информации и подготовка исходных данных
На этом этапе была обследована работа сотрудников страховой
фирмы, определены функции персонала, нормативы их работы. Выполнен
прогноз возможных входных потоков.
Обследование показало, что основными процессами системы
являются следующие:
1) Страхование
22
1.1) прием заявлений на страхование, продление срока, досрочное
прекращение;
1.2) оформление страхового полиса;
1.3) прием оплаты;
1.4) выдача страхового полиса;
2) страховые выплаты:
2.1) прием заявлений на выплаты;
2.2) осмотр автотранспорта, имущества;
2.3) рассмотрение документов, подготовка акта;
2.4) утверждение акта;
2.5) проведение страховых выплат.
В качестве объектов системы страхования были приняты:
1) руководитель – утверждает документы;
2) группа страхования - заключает договоры страхования;
3) группа выплат - оформляет страховые выплаты;
4) кассир – принимает и выплачивает деньги.
Таблица 15.
Средние интервалы времени поступлений входных заявок, определенные в ходе
обследования
Наименование документа
Интервал времени поступления,
час
лично
по почте
Заявление
и
документы
на
0,2
страхование
Заявление и документы на выплаты 2
20
Таблица 16.
Нормативы работы
Сотрудники
Вид работы
Время
выполнения
работы, час
КолМин.
во
0,5
Страховщик 3
0,05
Должность
Оформление документов
Выдача страхового полиса
Прием
документов
на
выплаты
Осмотр автотранспорта
Инспектор 1
Рассмотрение документов,
подготовка акта
Утверждение акта
Начальник 1
Прием оплаты
Кассир
1
23
Сред.
Макс.
0,75
0,08
1,0
0,1
0,17
0,25
0,5
0,25
0,63
1,0
0,2
0,33
0,5
0,05
0,05
0,08
0,08
0,1
0,1
Выплаты
0,08
0,12
0,15
4.2. Построение модели
Исходные данные для процесса страхования определяются с
помощью блоков генерации исходных данных (Create). Источником
данных являются страхователи, которые приносят «Заявления на
страхование» (блок «Orders to insurance»). Они подаются страховщикам,
которые находятся на рабочих местах приема документов.
Выполнение работ отображается блоками процессов (Process). По
заявлениям страховщик выполняет «Оформление документов» (блок
«Registration of orders to insurance»), после того, как страхователь оплатит
полис, производит «Выдачу страховых полисов» (блок «Delivery of
insurance policies»). Эта часть схемы отражена на рисунке 13.
Рисунок 13 – Процесс страхования
Для задания свойств модулю типа «Flowchart» необходимо дважды
щелкнуть по нему и в появившемся диалоге задать значения параметров.
24
Рисунок 14 – Задание параметров в блоке «Оформление документов»
Рисунок 15 – Задание параметров в блоке «Заявления на страхование»
Дополним схему рисунком, который при проигрывании модели
будет отражать состояние занятости страховщика (кнопка Resource на
панели инструментов). Нажав кнопку Open, вы можете выбрать ту
библиотеку изображений, которая соответствует вашему ресурсу. В
рассматриваемом примере открываем Workers.plb (возможный путь
C:\Program Files\Rockwell Software\Arena). Выберете место в области
построения модели для размещения изображения. Растяните изображение
до нужного размера.
25
Рисунок 16 – Состояния занятости страховщика
Аналогичным образом построим схему для процесса страховых
выплат.
Исходные данные для процесса страховых выплат определяются с
помощью блоков генерации исходных данных (Create). Источником
данных являются страхователи, которые приносят заявления на страховую
выплату лично (блок «Demands for insurance payments personally») или
присылают их по почте (блок «Demands for insurance payments by mail»).
Они подаются сотрудникам группы выплат, которые находятся на рабочих
местах приема документов по выплатам.
Выполнение работ отображается блоками процессов (Process). По
заявлениям сотрудник группы выплат выполняет «Прием документов»
(блок «demands registration»), осуществляет «Осмотр автотранспорта»
(блок «Motor checkup»), «рассматривает документы» (блок «Preparation of
certificates»). Эта часть схемы отражена на рисунке 17.
26
Рисунок 17 – Процесс страховых выплат
Рисунок 18 – Задание параметров в блоке «Прием документов»
27
Рисунок 19 – Задание параметров в блоке «Заявления лично»
Дополним схему рисунком, который при проигрывании модели
будет отражать состояние занятости сотрудника группы выплат.
На завершающем участке схемы отразим: утверждение актов на
выплаты руководителем центра («Statement of certificates»), работу кассира
по выплате страховки («Payments on insurance») и приему страховых
премий («Payment reception»). Дополним схему рисунками, которые будут
отражать состояние занятости руководителя и кассира.
Рисунок 20 – Процесс работы руководителя и кассира
28
Рисунок 21 – Задание параметров в блоке «Утверждение актов»
Рисунок 22 – Задание параметров в блоке «Прием оплаты»
29
Для руководителя создадим расписание работы по утверждению
документов - 1 час в конце рабочего дня. Для задания свойств модулю
Schedule или Resourse (типа “Data”) необходимо щелкнуть по нему один
раз на панели инструментов и в нижнем окне внести значения. Установим
для группы страхования число ресурсов, находящихся в системе, равным
3, поскольку по условиям задачи в этой группе работают 3 менеджера (для
ресурса Manager_insurance параметр Capacity). Для ресурса Chief
(руководитель) вместимость определяется модулем Schedule (параметр
Type).
Рисунок 23 – Задание расписания руководителя
Зададим стоимость ресурсов, чтобы проследить по результатам
моделирования какова будет стоимость выполнения всего процесса. В
полях Busy/Hour и Idle/Hour задайте часовую заработную плату
работников, также бонус страховщика за заключенный договор
страхования (стоимость обработки ресурсом одной сущности, поле Per Use
= 50).
Рисунок 24 – Задание параметров ресурсов
Кликнув по полю Durations (см. рисунок 23) переходим на форму
задания вместимости ресурса в зависимости от времени.
30
Рисунок 25 – Задание вместимости ресурса от времени
Для документов, полученных лично, выплаты осуществляются
непосредственно из кассы, а для документов, полученных по почте,
отправляются почтовыми переводами. Чтобы отразить этот факт введем
блок решения («Choice of a way of payment sending»), распределяющий
документы по разным выходным блокам в зависимости от способа
получения.
Рисунок 26 – Выбор способа передачи выплат
Приведем окна редактирования параметров для модулей Entity (см.
рисунок 27), Create (см. рисунок 28).
Рисунок 27 – Задание параметров сущностей
31
Рисунок 28 – Задание параметров источников
В результате наша схема будет иметь вид, отображенный на рис. 29.
Рисунок 29– Имитационная модель
Для добавления графиков, отражающих динамику прихода
страхователей, очереди страхователей, выдачи страховых полисов,
нажмите кнопку Plot на панели инструментов. Чтобы добавить выражение,
отображаемое на графике, нажмите Add. В появившемся окне Plot
Expression необходимо задать требуемое выражение. Можно выбрать из
предлагаемого выпадающего списка, или нажать правой кнопкой в поле
Expression и открыть построитель выражений (Build Expression).
32
Рисунок 30 – Построение графиков
4.3. Подготовка к запуску
Введите общую информацию о проекте и задать продолжительность
прогона.
1) Откройте окно свойств проекта используя меню Run → Setup →
Project Parameters. В поле Project Title введите имя проекта. Отметьте
необходимые параметры для сбора статистики (см. рисунок 31).
2) Затем в том же окне выберите Replication Parameters (см. рисунок
32). В поле Replication Length введите продолжительность прогона, в поле
Time Units выберите единицу измерения продолжительности. Настроим
имитацию 8-часового рабочего дня (Replication length установим равным 1
дню, Hours per Day – равным 8 часам). Число репликаций равно 10.
33
Рисунок 32 – Задание параметров
репликации
Рисунок 31 – Задание параметров
прогона
Для проигрывания модели необходимо перейти в меню Run/Go.
После проигрывания модели автоматически генерируются отчеты в
формате Crystal Reports.
Рисунок 33 – Результаты моделирования
4.4. Проведение расчетов на модели
При моделировании получим следующие результаты.
За день поступает в среднем 41,4 заявлений, 6,2 заявлений на
выплаты (из них 1,5 - по почте). Сотрудники оформляют 19 полисов,
проводят 3,9 страховых выплат (см. рис. 34).
В результате в группе страхования накапливается очередь 5,4598
(средний максимум – 9,6050) человек на оформление полисов и 3,7156
34
(средний максимум – 5,7446) человек на их получение. На страховые
выплаты и в кассе очередей практически нет (см. рисунок 35).
Рисунок 34 – Отчет моделирования(EntityOtherNumber In)
Рисунок 35 – Отчет моделирования(QueueOtherNumber Waiting)
Среднее время ожидания в очереди на оформление полиса
составляет – 0,9530 (средний максимум - 1,4631) час. Среднее время
ожидания в очереди на выдачу полиса составляет – 1,1484 (средний
максимум - 1,7198) час (см. рисунок 36).
А среднее время на оформление заявления на страхование - 1,6198
(максимум - 2,0812) час (с учетом времени на ожидание в очереди) (см.
рисунок 37).
Безусловно, такие показатели работы являются неприемлемыми. В
реальной жизни заявители просто не будут так долго стоять в очереди, а
просто уйдут.
35
Рисунок 36 – Отчет моделирования(EntityTimeWaiting Time)
Рисунок 37 – Отчет моделирования(ProcessTime per Entity)
На следующем рисунке приведен график, который отражает
динамику поступления заявлений на страхование и выдачи страховых
полисов, а также очередь на этапе оформления документов.
Рисунок 38 – Начальный график результатов моделирования
Теперь определим в состав группы страхования 5 человек. В
результате получим следующее.
Рисунок 39– Конечный график результатов моделирования
36
При том же объеме поступлений оформляется в среднем уже 32,9
полиса, 4 страховых выплаты. В группе страхования очередь составит
теперь в среднем 0,6536 человека на оформление полисов и 0,7663
человека на их получение. Среднее время ожидания в очереди на
оформление полиса составляет – 0,1224 (0,3165) час, а время на
оформление, - 0,8711 (1,0580) часа (с ожиданием).
Можно оценить и степень занятости персонала, которая будет для
группы страхования - 0,74, группы выплат – 0,84, кассира – 0,38,
руководителя – 0,31 (конечно, только по утверждению документов, т.к.
другие обязанности мы не рассматриваем).
Рисунок 40 – Отчет моделирования(ResourceUsageScheduled Utilization)
Вывод: Такая численность группы страхования (5 человек)
представляется более приемлемой, чем предложенная первоначально.
Литература:
1)
Simulation with Arena. W.David Kelton, Randall P. Sadowski, David T Sturrock. McGraw. Hill Higher Education, ©2007
2)
Simulation Modeling and Analysis with ARENA. Tayfur Altiok,
Bengamin Melamed. Academic Press, ©2007
3)
Из опыта использования средства Arena для моделирования
работы центра страхования автогражданской ответственности. А.
Свечников // http://www.iteam.ru/publications/it/section_51/article_2264/
37
Составители: к.т.н. Дмитрий Михайлович Коробкин,
д.т.н. Сергей Алексеевич Фоменков.
ПОСТРОЕНИЕ СТОХАСТИЧЕСКИХ ДИНАМИЧЕСКИХ МОДЕЛЕЙ С
ИСПОЛЬЗОВАНИЕМ СИСТЕМЫ ARENA 9.0
Методические указания
Редактор Е.И. Кагальницкая
Темплан ____ г. Поз. № __.
Подписано в печать ________. Формат 6084 1/16.
Бумага газетная. Печать офсетная. Усл. печ. л. 1,4.
Уч.-изд. л. 1,45. Тираж 150 экз. Заказ __________.
Волгоградский государственный технический университет.
4000131, Волгоград, пр. Ленина,28.
РПК «Политехник» Волгоградского государственного
технического университета.
400131, Волгоград, ул. Советская, 35.
38
1/--страниц
Пожаловаться на содержимое документа