МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ

РОССИЙСКОЙ ФЕДЕРАЦИИ

ФГБОУ ВПО «РОСТОВСКИЙ ГОСУДАРСТВЕННЫЙ

ЭКОНОМИЧЕСКИЙ УНИВЕРСИТЕТ (РИНХ)»

Щербаков С.М.

ИМИТАЦИОННОЕ МОДЕЛИРОВАНИЕ ЭКОНОМИЧЕСКИХ

ПРОЦЕССОВ В СИСТЕМЕ ARENA

Учебное пособие

г. Ростов-на-Дону 2012 УДК 330.4 (075)+004 (075) Щ 61 Щербаков, С.М.

Щ 61 Имитационное моделирование экономических процессов в системе Arena: Учебное пособие / С.М. Щербаков ; Рост. гос. эконом. ун-т (РИНХ). – Ростов н/Д, 2012. – 128 c.

ISBN 978-5-7972-1868-5 Учебное пособие предназначено для изучения основ практической работы с одним из наиболее распространенных и мощных инструментов имитационного моделирования Rockwell Arena. Детально описаны возможности системы и принципы работы с нею. Представлены и разобраны примеры решения задач моделирования различного уровня и различной направленности.

Учебное пособие предназначено для студентов всех форм обучения направлений «Прикладная информатика», «Бизнес-информатика».

Утверждено учебно-методическим советом университета Рецензенты:

Хубаев Г.Н. д.э.н., профессор, Ростовский государственный экономический университет (РИНХ) Стредльцова Е.Д. д.э.н., профессор, Южно-Российский государственный технический университет (НПИ) © Ростовский государственный экономический университет (РИНХ), Содержание Введение

1 Основные понятия системы Arena

2 Базовые модули системы Arena

3 Ветвление. Использование выражений

4 Атрибуты, очереди, приоритеты

5 Анимация и визуализация моделей

6 Использование пулов (set) ресурсов

7 Использование шлагбаумов

8 Слияние, расщепление и синхронизация транзактов

9 Методы передачи транзактов. Использование станций

10 Проведение имитационного эксперимента в Арена

Заключение

Литература

Вопросы к экзамену

Введение Управление предприятием или организацией предполагает принятие решений в условиях действия большого числа внешних факторов, наличия множества взаимодействующих элементов управляемой системы и ориентировано на достижение комплекса различных целей. Средством обеспечения эффективности принимаемых решений служит моделирование Модель - искусственный объект, представляющий собой отображение (образ) системы и ее компонентов. Считается, что М моделирует А, если М отвечает на вопросы относительно А. Здесь М - модель, А - моделируемый объект (оригинал) 1.

Часто сложность управляемой системы и наличие значительной стохастической составляющей делают наиболее эффективным использование имитационных моделей. Имитационная модель обладает высокой степенью изоморфизма изучаемой системе, позволяет рассматривать значительное число деталей деятельности предприятия, учитывает случайные факторы.

Эксперименты над имитационной моделью способствуют получению оценки различных вариантов предлагаемых управленческих решений.

Сегодня для построения имитационных моделей используют развитые системы, включающие графический интерфейс построения моделей. Наиболее распространенные средства: AnyLogic, Extend, Arena. Система Rockwell Arena – один из наиболее мощных и популярных инструментов имитационного моделирования – будет рассматривать в настоящем учебном пособии.

При изучении работы с Arena следует обратить внимание на книгу:

Simulation with Arena, 5th Edition by W. David Kelton, Randall P. Sadowski, Nancy B. Swets Rockwell Automation McGraw-Hill, 2010.

Это официальный учебник по имитационному моделированию в системе Arena, разработанный сотрудниками фирмы Rockwell Automation.

Вместе с системой Arena поставляется несколько электронных книг с документацией, из которых прежде всего вызывает интерес Arena Users Guide, где дается описание большинства модулей. Важным источником знаний являются и примеры моделей, представленные вместе с системой.

Кроме примеров моделей, с системой поставляются SMARTS – небольшие фрагменты моделей, отражающие тот или иной аспект использования Arena, например, работу с ресурсами или передачу транзактов между станциями.

На русском языке информации по системе существенно меньше. Большинство статей, материалов в сети Интернет и отдельные имеющиеся методические разработки посвящены описанию только модулей шаблона Basic Prrocess. Эти материалы можно использовать на начальном этапе изучения системы.

Рекомендации по стандартизации. – М.: ГОССТАНДАРТ РОССИИ, 2001.

Что касается изучения методологии имитационного моделирования, то по ней имеется достаточно большой объем отечественной и переводной литературы. В частности, можно рекомендовать книгу:

Шеннон Р. Имитационное моделирование систем – искусство и наука.

– М.: Мир, 1978. – 417 с.

Книга описывает основные идеи имитационного моделирования, цели и задачи построения моделей. В большинстве случаев именно по этой книге излагается в различных курсах и учебниках процесс имитационного моделирования.

Также следует обратить внимание на книгу:

Лоу А., Кельтон В. Имитационное моделирование. – СПб: Питер, 2004.

– 848 с.

Эта книга раскрывает большинство аспектов имитационного моделирования: получение исходной информации, генерация случайных чисел, планирование имитационных экспериментов и т.д.

Что касается учебников по имитационному моделированию, то в большинстве случаев они ориентированы на какую-то конкретную систему имитационного моделирования. Значит, полезна для изучающего может быть только «общая часть» учебника, посвященная методологии моделирования. С другой стороны, преимуществом учебников является достаточно компактный объем и простота изложения. В частности можно рекомендовать книги:

Емельянов А. А., Власова Е. А., Дума Р. В. Имитационное моделирование экономических процессов. – М.: ФиС, 2009. – 416 с.

Томашевский В., Жданова Е. Имитационное моделирование в среде GPSS. – М.: Бестселлер, 2003. – 416 с.

В настоящем учебном пособии будут раскрыты особенности использования системы Arena для построения имитационных моделей в экономике и управлении.

1 Основные понятия системы Arena Имитационная модель в системе Arena представляет собой граф (рисунок 1), узлами которого являются модули. Модули связаны между собой с помощью соединений, по которым между модулями перемещаются транзакты 2.

Чтобы создать модель на языке Arena достаточно:

1) задать транзакты, ресурсы и другие объекты;

2) выбрать необходимые модули;

3) связать модули с помощью соединений;

4) задать параметры каждого из модулей;

5) задать характеристики модели в целом.

Модели в системе Arena являются процессно-ориентированными, граф модели показывает путь отдельного транзакта. Транзакт создается, ожидает в очереди, захватывает ресурсы, обрабатывается, освобождает ресурсы, уничтожается. Параллельно такой же путь могут проходить и другие транзакты, но задачу управления процессами берет на себя система.

Рассмотрим базовые понятия системы Arena, используемые при построении моделей. К таким понятиям следует отнести 3:

- транзакт (entity);

- переменная;

- очередь (queue);

- расписание (schedule) 2 Транзакт – динамический объект имитационной модели.

На самом деле есть и другие понятия – станция, последовательность. транспортер и т.д.

Они будут рассмотрены далее в следующих главах.

Транзакт (entity, в терминах системы Arena) – это динамический объект имитационной модели, который перемещается между статическими узлами модели. Примеры транзактов – деталь, автомобиль, клиент, документ и т.д.

В модели может участвовать несколько транзакты разных типов, которые задаются разработчиком модели. Тип транзакта может меняться динамически, например, на каком-то этапе транзакт «машинокомплект» меняет свой тип на «автомобиль».

Транзакту соответствует картинка для анимации, с ее помощью можно следить за перемещениями транзактов между модулями и за обработкой транзактов.

Характеристики транзактов задаются с помощью атрибутов. Существуют системные атрибуты, установленные по умолчанию. Например, «время существования транзакта» (Total Time), «серийный номер транзакта» (Serial Number), тип транзакта (Entity Type) и т.д. Имеется атрибут «картинка» (Entity Picture), поменяв программно его значение можно изменить визуальное изображение транзакта.

Кроме того, пользователь может присваивать собственные атрибуты транзакта: «вес детали», «число покупок, совершенное покупателем супермаркета», «длина пакета данных», «сумма накладной» и т.д. Пользовательские атрибуты будут определять в дальнейшем время обработки транзакта, его приоритет при обработке, дальнейший путь транзакта.

Атрибуты транзактов позволяют собирать статистику по времени (сколько времени транзакт пробыл в модели, сколько обрабатывался, сколько ожидал и т.д.) и по стоимости (например, оценивать себестоимость изделия после прохождения технологического процесса).

Для создания транзактов используем невизуальный модуль Entity.

Переменная (Variable) – это глобальная переменная модели. Ее значение может считываться и изменяться во время моделирования. От значения переменной может зависеть, например, возможность прохождения некоторого участка: детали будут проходить обработку, если установлено значение некоторой глобальной переменной, свидетельствующей о том, что разрешение руководителя получено. Еще пример – счета могут проходить далее при наличии некоторой минимальной суммы в кассе предприятия. При оплате каждого счета это значение меняется 4.

Важно отличать атрибут транзакта от переменной. Значение переменной одно на всю модель. В то же время у каждого транзакта может быть свое значение некоторого атрибута. В наших примерах – число денег в кассе – это переменная, глобальное единственное Переменные могут также быть одномерными и двумерными массивами. Обращение к элементам массива осуществляется так же как в обычных языках программирования A(5) или B(3,2).

Для создания переменных используем невизуальный модуль Variable.

Здесь задается имя переменной. Если это массив – нужно задать число строк Rows и столбцов Columns (для одномерных – только строк, Rows).

Кнопкой в колонке Initial Values вводим начальное значение (или для массивов - значения) переменной. Это значение переменная будет иметь при старте прогона модели.

Существуют и системные переменные, важнейшая из них – TNOW, текущее значение модельного времени 5.

Ресурс. Ресурсы разделяются между транзактами, транзакты конкурируют за ресурсы. Например, детали обрабатываются на станке, клерк рассматривает заявления, сервер обрабатывает запросы и т.д.

По ходу моделирования транзакт захватывает ресурс (если не может захватить – ожидает пока ресурс освободится), использует его перемещаясь по модели, затем отпускает ресурс.

Важнейшая характеристика ресурса – мощность, число единиц ресурса. Примеры: число каналов для телефонных разговоров, число окошек в банке, число одинаковых станков и т.д.

Arena позволяет задать для ресурса характеристики стоимости – сколько стоит час единицы ресурса когда он свободен, занят, сколько стоит одно обращение к ресурсу и т.д.

Ресурсы задаются с помощью невизуального модуля resource.

значение,. А вот сумма документа «Счет-фактура» - это атрибут. У каждой счет-фактуры своя сумма.

В базовых единицах времени. Базовые единицы выставляются в пункте меню Run – Setup вкладка Replication parameters.

Здесь для обоих ресурсов задано имя и указано, что ресурс имеет фиксированную мощность. И задана мощность (capacity) – в цеху работает один мастер и пятеро рабочих.

Для ресурса можно задать расписание. Например, продавцы супермаркета могут приходить на работу по определенному графику с целью лучше обслуживать покупателей в часы максимальной посещаемости.

Расписание задается в невизуальном модуле Schedule. При создании ресурса с расписанием вместо опции «Fixed capacity» указываем «by Schedule» и выбираем это расписание.

В ходе моделирования ресурс принимает одно из следующих состояний :

- IDLE (свободен);

- FAILED (неисправен);

- INACTIVE (отключен).

Пользователь может создавать и собственные состояния.

Очередь (queue) – может образовываться возле тех модулей, которые мешают транзакту пройти дальше. Пример – станок для обработки деталей занят, и деталь ожидает в очереди, пока он освободится. Шлагбаум на железнодорожном переезде закрыт (идет поезд) и поэтому автомобили образуют очередь, чтобы ожидать открытия шлагбаума. Еще пример – детали нужно Для ресурсов с мощностью большей единицы состояние следует трактовать так: IDLE – все единицы свободны, BUSY – хотя бы одна занята.

упаковать по 12 штук. По мере поступления деталей они будут ожидать упаковки в очереди, до тех пор, пока не появятся 12-ая.

Очереди создаются автоматически, но разработчик модели имеет возможность управлять их свойствами. Важнейшим свойством очереди является ее тип, определяющий поведение транзактов в очереди. Существуют четыре типа:

- FIFO – «First in first out». Первый пришел - первый вышел. Наиболее распространенный случай, используется по умолчанию;

- LIFO – «Last in first out». Последним пришел - первым вышел. Такая очередь называется «стек». Пример – партии товара помещаются в хранилище. По мере освобождения упаковочной машины товар достается, упаковывается и передается дальше. Склад устроен так, что поступившие вновь товары закрывают доступ к поступившим ранее (вспомним междугородние автобус и его багажное отделение);

- Lowest Attribute Value. По наименьшему значению атрибута;

- Highest Attribute Value. По наибольше значению атрибута.

Последние два метода позволяют реализовать очередь с приоритетом.

Для этого нужно завести искусственный пользовательский атрибут, указывающий приоритет для каждого типа транзакта. Например, машины скорой помощи (значение атрибута «1») будут попускать вперед. Если в очереди три обычных машины (значение атрибута «0»), то прибывшая машина скорой помощи займет место перед ними – т.е. в начале очереди. А вот следующая машина скорой помощи займет место после первой машины скорой помощи перед обычными машинами.

Приоритет может базироваться и на каком-то естественном, содержательном атрибуте, например, вес детали, сумма денежного перевода и т.д.

В чем заключается разница между атрибутом и переменной?

Каким образом можно организовать очередь с приоритетом?

Что означает характеристика ресурса «Capacity»?

Что означают состояния ресурса «BUZY» и «IDLE»?

В каких случаях модуль будет иметь возле себя очередь?

Можно ли менять значение переменной во время моделирования?

Сколько значений атрибутов имеется в модели во время моделирования?

Библиотекарь обслуживает подходящих к нему читателей. Чем будут «библиотекарь» и «читатель» с точки зрения системы Arena?

10) Каждый читатель хочет взять какое-то количество книг. Чем будет «количество книг, которые хочет получить читатель» с точки зрения системы Arena?

11) Библиотека платная и за каждую взятую книгу читатель должен внести 10 рублей. Чем будет «полученная в течение дня выручка библиотеки» с точки зрения 12) Директор магазина выставляет большее число кассиров, чтобы облегчить обслуживание покупателей в «час пик». Как это отразить в системе Arena?

2 Базовые модули системы Arena Модуль Create (генератор транзактов) – вводит транзакты в модель.

Например, покупатели приходят в магазин, суда прибывают в порт, в службу поддержки поступают звонки и т.д.

Обозначение:

Модель может включать несколько модулей Create.

На рисунке показано окно параметров для модуля Create, где можно задать, например, как часто должны поступать транзакты.

Рисунок говорит о следующем: клиенты парикмахерской заходят примерно раз в 15 минут, закон распределения интервала между клиентами – экспоненциальный.

Для модуля задаются такие параметры:

- название модуля (Name 7);

- тип поступающего транзакта (Entity type);

- интервал между прибытиями транзакта (Time Interval);

- число транзактов при каждом поступлении (Entities per arrival);

- максимальное число поступлений (Max Arrivals).

Интервал может быть задан как:

- «константа» (Constant). Транзакты поступают в модель строго через равные промежутки времени. Например, деталь поступает на участок обработки строго один раз в минуту Настойчиво рекомендуем сразу же при создании присваивать всем модулям содержательные, «говорящие» имена. В противном случае понимание модели будет затруднено.

- «по расписанию» (Schedule). В этом случае следует выбрать расписание. Например, в течение дня у магазина наблюдается разная интенсивность поступления клиентов – в «часы пик» она значительно увеличивается.

- «выражение» (Expression) Указывается функция распределения и ее параметры. Так, на рисунке показано, что интервал поступления транзактов подчиняется равномерному закону распределения и может составлять от до 20 минут unif(10,20).

- «случайный» (Random(Expo)). В системах массового обслуживания очень часто встречается пуассоновский поток заявок. При таком потоке интервал времени между появлениями заявок подчиняется экспоненциальному закону распределения. Для отражения этого частого случая и предусмотрена опция «Random (expo)». Можно выбрать ее и задать математическое ожидания интервала. Эта опция введена для удобства. С тем же результатом можно использовать выражение expo(15).

Задавая интервал необходимо выбрать единицу измерения времени 8.

Для модуля Create задается число транзактов при каждом поступлении (Entities per arrival). Чаще всего поступает один транзакт, но модуль Create может вводить транзакты партиями. Например, согласно технологическому процессу, в цех поступают одновременно 5 деталей (рабочий раз в 7-10 минут привозит тележку, с пятью деталями). Мы можем считать детали транзактами и указать, что они всегда поступают по 5.

Можно смоделировать и ситуацию, когда люди заходят в магазин группами 1-4 человека. В поле «Entities per arrival» указываем выражение unif(1,4), значит при каждом поступлении прибывает от одного до четырех транзактов.

В поле «максимальное число поступлений» (Max Arrivals) обычно стоит значение по умолчанию «Infinite», бесконечность. Поле позволяет ограничить число транзактов в модели. Например, грузовики прибывают в гараж, где их проверяют, обслуживают и ставят на ночь. Но у фирмы ограниченное число грузовиков и, значит, в какой-то момент поступит последний.

Как правило, эту возможность используют для так называемых, «замкнутых схем». «Открытая схема» – транзакты приходят в модель (генерируются, создаются), затем после необходимого обслуживания, уничтожаются, выводятся из модели. При «закрытой схеме» все выглядит иначе – в модель Небрежность при выборе единиц измерения времени – одна из наиболее распространенных ошибок при создании моделей.

вводится определенное число транзактов, которые затем циркулируют внутри модели. Например, у фирмы 10 автобусов. Они проходят обслуживание и уходят на маршрут, затем возвращаются и вновь уходят и т.д.

Модуль Dispose (терминатор транзактов) – выводит транзакты из модели (уничтожает транзакты). Например, покупатели после покупки товара, покидают магазин.

Обозначение:

Модуль Process (обработка, действие) – моделирует обработку транзактов: обслуживание покупателей продавцом, разгрузку судна, ремонт телевизора и т.д. Обратим внимание, что с точки зрения имитационной модели «обработка» означает задержку транзакта на определенное время, содержательный смысл этой задержки определяется исследователем.

Обозначение:

Обработка транзактов может потребовать использования ресурсов. Так, для сверления детали нужен соответствующий станок, для обслуживания покупателя – продавец и т.п.

Арена обеспечивает достаточную гибкость работы с ресурсами. Обработка может потребовать нескольких единиц ресурсов, либо может потребовать несколько разных ресурсов. Например, для профилактического осмотра автомобиля нужны два рабочих автосервиса и смотровая яма. Транзакт может «захватить» ресурс и перемещать его за собой по модели, с тем, чтобы потом «отпустить». Автомобиль «захватывает» яму, затем его осматривает одна бригада рабочих, затем другая бригада выполняет кузовные работы, затем автомобиль «отпустит» яму.

Существует четыре типа модуля Process:

- Delay, задержать. Не требуется никаких ресурсов. Пример: покрашенный стол выставляется на улицу, где он должен просохнуть. Столы не конкурируют ни за какой ресурс – одновременно на солнце может сушиться неограниченное число столов.

- Seize-Delay-Release, захватить-задержать-отпустить. Пример: деталь поступила на станок, была просверлена и освободила станок. Это наиболее распространенный вариант модуля.

-Seize-Delay, захватить – задержать.

- Delay-Release, задержать-отпустить.

Два последних варианта используются для построения сложных мноногофазных процессов, предполагающих несколько стадий обработки. Захватив ресурс, транзакт может удерживать его несколько операций.

В случае, если модуль Process предполагает захват какого-то ресурса (то есть типы Seize-Delay-Release или Seize-Delay), к модулю автоматически добавляется очередь. Если нужного ресурса нет в наличии (сломан, неактивен согласно расписанию или занят другими транзактами) транзакт будет ожидать его освобождения в очереди:

Пример модуля Process приведен на рисунке. Как видим, здесь используется тип Seize-Delay-Release. Процесс носит имя «стрижка». Для процесса необходим один парикмахер. Время стрижки распределено по треугольному закону распределения, причем на стрижку может уйти от 15 минут (минимальное значение) до 30 минут (максимальное) при том, что 20 минут – это наиболее вероятное значение.

Рассмотрим более подробно параметры модуля. Окно распадается на три зоны. В первой зоне заполняем имя операции - Name (так же как для любого другого модуля Арены).

Вторая зона отвечает за тип процесса и за используемые ресурсы.

В списке Action нужно выбрать необходимый тип модуля.

Если выбран тип Delay, то больше ничего указывать не нужно, никакие ресурсы для операции не требуются.

Если же выбран другой тип, то нужно явно указать, какие именно ресурсы и в каких количествах нужны для выполнения операции:

На рисунке выше показано, что для выполнения операции нужны три штуки первого инструмента и одна штука второго инструмента.

Операция может потребовать нескольких единиц ресурсов, например, для разгрузки большого судна нужно два портовых крана.

С помощью кнопок Add (добавить), Edit (редактировать), Delete (удалить) можно управлять списком необходимых ресурсов.

Окно редактирования ресурса:

В окне следует выбрать из списка имя ресурса (предполагается, что ресурсы мы создали заранее. Можно, однако, ввести имя несуществующего пока ресурса, в этом случае ресурс будет создан автоматически). В поле Quantity (количество) вводим число единиц ресурса, необходимых для выполнения операции над одним транзактом 9.

В окне редактирования ресурсов имеется еще одно поле – Type. Здесь можно выбрать один из двух вариантов: Resource (конкретный ресурс) или Set (множество, пул ресурсов). Работа с пулами ресурсов будет рассмотрена в главе 6.

В поле Priority нужно указать приоритет операции. Дело в том, что один и тот же ресурс может использоваться в нескольких модулях Process. С помощью поля приоритета можно указывать, какая из операций, требующая этого ресурса начнется первой 10. Например, сотрудник паспортного стола выполняет две операции – «прием заявления» и «выдача паспорта». Приоритет второй операции выше – это значит, что при наличии людей, ожидающих обоих операций сотрудник в первую очередь станет обслуживать тех, кто пришел получить готовый паспорт.

Вне зависимости от выбранного типа модуля Process необходимо задать время исполнения операции (зона 3):

В целом, работа ведется аналогично модулю Create. Нужно указать способ определения времени, единицу измерения времени. Разработчики системы по умолчанию предлагают треугольный закон распределения с тремя параметрами – минимальным, наиболее вероятным и максимальным временем исполнения операции.

Не путаем это значение с мощностью ресурса, то есть числом единиц, которое имеется в модели! Например, в мастерской может работать пять рабочих, а для ремонта кузова одного автомобиля нужна совместная работа двух рабочих.

Необходимо понимать разницу между ресурсом, например, станком и процессом, например обработкой детали на станке. Модуль Process представляет именно операцию, протекающий во времени процесс, стадию обработки. Эта разница должна отражаться и в названиях, которые присваиваются модулю Process и ресурсам.

Другие варианты:

- фиксированное время (Constant), операция всегда занимает четко заданное время.

- нормальное распределение времени обслуживания (Normal). В этом варианте следует задать два параметра – математическое ожидание и среднеквадратическое отклонение (как показано на рисунке).

- равномерное распределение времени обслуживания (Uniform). Задается минимальное и максимальное время.

- выражение (Expression). Можно ввести выражение, показывающее необходимое время обслуживания. Например, если время обслуживание подчиняется экспоненциальному закону, то можно указать expo(15).

Выражения позволяют более гибко управлять временем обработки транзактов. Например, транзакт-вагон может иметь атрибут mass, показывающий вес груза. А время разгрузки может зависеть от веса: 10*mass. Чтобы включить элемент случайности expo (10*mass).

Последнее поле Allocation позволяет отнести время, проведения операции к одной из категорий, для последующего анализа. Например, в данном случае указано, что операция относится к «создающим стоимость» (Value Added). В дальнейшем по результатам моделирования мы сможем определить какой процент времени тратится на создание стоимости, какой – на вспомогательные операции, какой – на ожидание. Так можно судить об эффективности моделируемых процессов.

После того, как мы изучили три первых модуля 11, можем приступить к созданию первой простейшей модели.

Пример 1. Клиенты заходят в парикмахерскую раз в 15 минут (закон распределения интервала времени прихода клиентов экспоненциальный). В парикмахерской работают два парикмахера, которые тратят на стрижку клиента от 20 до 40 минут, закон распределения – равномерный.

Прежде всего, необходимо определиться с важнейшими понятиями:

- клиент – это транзакт.

- парикмахер – это ресурс.

Модули, которые мы рассмотрели, относятся к шаблону Basic Processes. Следующий шаблон Advanced Process содержит модули, позволяющие строить более сложные и гибкие модели. К этому шаблону относятся и модули Sieze, Delay, Release. Их функционал почти полностью сходен с функционалом модуля Process.

Кроме того, модули Sieze позволяет использовать общие очереди к одним и тем же ресурсам Создадим с помощью невизуального модуля Entity (шаблон Basic Process) транзакты-клиенты. Дадим транзакту имя и выберем подходящую картинку:

Теперь с помощью невизуального модуля Resource создадим парикмахера. Здесь мы задали имя ресурса – Barber:

В поле Type укажем, что используется фиксированная мощность ресурса (fixed capacity). Далее в поле capacity (мощность) задаем число единиц ресурсов, имеющихся в наличии – 2 парикмахера.

Остальные параметры мы не используем в модели, эти параметры отвечают за стоимость ресурсов: Busy/Hour (стоимость часа ресурса если он занят), Idle / Hour (стоимость часа ресурса, если он простаивает), Per Use (стоимость единичного обращения к ресурсу).

Теперь можно создавать граф модели:

Чтобы нарисовать граф достаточно вытянуть на рабочую плоскость необходимые модули один за другим, при этом они будут соединяться автоматически. Также можно использовать инструмент соединения с панели инструментов.

Рассмотрим параметры отдельных модулей. На рисунке показано окно параметров модуля Create:

На следующем рисунке приведено окно параметров модуля Process. У модуля Process имеется очередь. Обратим внимание, что это единая очередь для всех мастеров, как только освобождается один из мастеров, первый клиент в очереди садится в его кресло.

Теперь необходимо определить параметры модели в целом. Для этого обращаемся к пункту главного меню Run-Setup. Здесь нас интересует вкладка Replication Parameters.

Здесь можно задать число повторений прогона модели «Number of Replication».

Далее определяем длину интервала моделирования «Replication Length», в примере мы уставили 8 часов. Если оставить значение по умолчанию – работа будет продолжать бесконечно до того, как пользователь остановит моделирование или пока наступит условие окончания.

В окне можно указать так называемый Warm-up период, результаты которого учитываться не будут 12.

Наконец, очень важно выбрать в Base Time Units единицу времени, наиболее подходящую для конкретной модели. Именно в таких единицах будут выводиться отчеты о моделировании, а также именно она будет использоваться в специальных функциях, которые обращаются к времени.

Поле Terminating Condition позволяет указать условие завершения моделирования. Например, мы могли бы задать здесь выражение, которое завершит моделирование при успешном обслуживании 100 клиентов.

Назначение периода warm up будет рассмотрено позже в главе 9.

Посмотрим на приведенный ниже листинг, он получен с помощью пункта меню Run – SIMAN - VIEW:

; Model statements for module: BasicProcess.Create (ClientCome) 1,HoursToBaseTime(0.0),Client:HoursToBaseTime(EXPO(15)):NEXT(3$) 3$ ASSIGN: ClientCome.NumberOut=ClientCome.NumberOut + 1:NEXT(1$);

; Model statements for module: BasicProcess.Process (HairCut) 1$ ASSIGN: HairCut.NumberIn=HairCut.NumberIn + 1:

9$ QUEUE, HairCut.Queue;

7$ DELAY: Uniform(20,40),,VA;

6$ RELEASE: Barber,1;

54$ ASSIGN: HairCut.NumberOut=HairCut.NumberOut + 1:

; Model statements for module: BasicProcess.Dispose 1 (ExitModel) 0$ ASSIGN: ExitModel.NumberOut=ExitModel.NumberOut + 1;

Этот программный код был автоматически сформирован системой Arena на основе созданного нами графа и его параметров. В тексте программы легко угадываются работа отдельных модулей. Мы видим, что для каждого из модулей потребовалось несколько строк программного кода.

Теперь запустим модель с помощью специальной панели инструментов:

Эта панель позволяет запускать приостанавливать модель, прокручивать ее без анимации, регулировать скорость моделирования, выполнять моделирование по шагам.

Вид графа модели во время моделирования показан на рисунке. Видны перемещающиеся между модулями транзакты.

На рисунке можно увидеть следующее: поступили 17 клиентов; два клиента находятся в очереди на стрижку; один парикмахер занят; только что освободился второй парикмахер – его клиент покидает модель.

На самом деле с точки зрения модельного времени изменения происходят мгновенно, время на перемещение между блоками не тратится. Как только обслуживание клиента закончилось, он покидает модель, а следующий занимает его место. Арена демонстрирует перемещение транзактов между модулями для наглядности.

Рассмотрим теперь модель с несколькими процессами.

Пример 2. Имеется некоторый технологический процесс. Поступающие детали (интервал поступления 10 минут, закон распределения экспоненциальный) помещаются на специальную тележку (имеется 3 таких тележки) и подвергаются грунтовке (операция выполняется 8±2 минут рабочим №1), затем окраске (6±2 минуты, рабочим №2), затем проходят просушку в течение 20 минут, затем снимаются с тележки и освобождают цех.

Очевидно, что для данного примера:

- транзакт – деталь;

- ресурсы: тележка, рабочий №1, рабочий №2.

Окно создания ресурсов:

На следующем рисунке показан граф модели. Обратим внимание на одну особенность - ресурс «тележка» захватывается транзактом в модуле Take Cart и удерживается в течение нескольких операций.

Рассмотрим модель и ее составляющие более подробно. Транзактыдетали поступают в модель с помощью модуля DetailCome типа Create. Далее происходит захват тележки (cart) в модуле TakeCart.

Как видим из следующего рисунка, выбран тип модуля Seize-Delay.

После прохождения модуля деталь будет удерживать за собой ресурстележку. Время задержки в модуле нулевое.

Далее осуществляется грунтовка и окраска. Это модули типа SeizeDelay-Release, ресурсом выступают рабочие (worker1 для грунтовки, worker для окраски). Время выполнения операции подчинено равномерному закону.

Так для грунтовки выставлено минимальное время 6, максимальное 10 минут, в соответствии с условиями задачи:

Модуль Process, соответствующий операции сушки детали имеет тип Delay, это значит, что никаких дополнительных ресурсов (кроме тележки, которую по-прежнему удерживается деталью) для операции не нужно. Время отводимое на сушку – строго 20 минут, задано с помощью константы.

Обратим внимание, что во всех модулях, предполагающих захват ресурса появляются очереди. В них детали будут оставаться в случае, если не окажется свободного ресурса до тех пор, пока такой ресурс не освободится.

Граф модели в процессе прогона:

Фрагмент отчета по результатам моделирования:

По результатам моделирования видно, что «узким местом» является модуль Process «TakeCart», то есть детали ожидают тележки. Это видно из рисунка, а также из фрагментов отчета: разница времени нахождения в очередях и разница в загрузке ресурсов.

Для повышения эффективности системы добавим еще одну тележку (изменим мощность, capacity ресурса «тележка» в невизуальном модуле Resources).

Отчет после прогона измененной модели:

Время ожидание в очереди значительно сократилось, загрузка ресурсов выровнялась, производительность системы возросла.

1) Какой модуль отвечает за обслуживание транзакта?

2) В каких случаяx модуль Process будет иметь очередь?

3) Какой типа модуля Process следует выбрать для операции, соответствующей переходу транзакта-работника к месту выполнения работы?

4) Может ли транзакт в модуле Process использовать сразу несколько единиц ресурса?

5) Может ли транзакт в модуле Process использовать сразу несколько различных 6) Каким образом нужно настроить модуль Create чтобы организовать «замкнутую схему», при которой ограниченное число транзактов будет циркулировать внутри модели не покидая ее?

7) Может ли интервал времени между приходом транзактов быть случайной величиной?

8) Какова важнейшая характеристика ресурса, которую можно получить в результате моделирования?

9) Что делает модуль Dispose?

10) Как сделать, чтобы в отчетах по результатам моделирования время выводилось в минутах?

11) Если транзакт «захватил» ресурс и удерживает его, перемещаясь по модели, как он сможет «отпустить» ресурс?

12) Как задать графическое изображение транзакта?

3 Ветвление. Использование выражений Модуль ветвления Decide – направляет входящие транзакты по одной из исходящих ветвей в зависимости от условия или случайным образом.

Обозначение:

Таким образом, модуль Decide позволяет реализовать модели с ветвлением, реализовать какой-то условие. Отметим, что прохождение транзактом модуля Decide происходит мгновенно, не занимает модельного времени 13.

Существует два варианта модуля Decide – «По вероятности» (by chance) или по условию (by condition). Тип задается в параметрах модуля.

Параметры модуля:

Выбран вариант «по вероятности». Задается вероятность того, что транзакт последует по правой ветке в процентах (Percent True). В данном случае, документ заполнен правильно с вероятностью 90%.

Другие примеры с модулем Decide «по вероятности»: деталь оказалась бракованной; клиент нуждается в дополнительных услугах; автомобилю нужно свернуть налево и т.д.

Модуль Decide может иметь не две, а несколько исходящих ветвей. Это относится как к варианту «по условию», так и к варианту «по вероятности».

На рисунке показан случай, когда студент может получить одну из четырех оценок, от чего будет зависеть дальнейшая обработка соответствующего транзакта.

При описании модулей мы будем явно говорить, будет ли в нем задержан транзакт. Если такого указания нет – значит модуль проходится мгновенно.

Окно параметров приведено на следующем рисунке. Выбран вариант «N-way by Chance», то есть несколько вариантов с вероятностью. Теперь необходимо задать вероятность в процентах для всех правых ветвей. Само собой, сумма должна быть меньше 100%. В нашем примере, вероятность получить «отлично» составляет 10%, «хорошо» – 30%, «удовлетворительно» – 50%, «неудовлетворительно» – оставшиеся 10% (нижняя ветвь Else).

Тип модуля Decide «По условию» («by condition») позволяет направлять транзакты в зависимости от значения некоторого логического выражения истина/ложь. Например: машины с весом, превышающим некоторый лимит, направляются на объездную дорогу; если какое-то устройство занято, агрегат направляется на резервное устройство, документ определенного типа пересылается заданному исполнителю и т.д.

В примере на следующем рисунке предполагается, что у транзактагрузовика 14 имеется атрибут mass. Если значение этого атрибута больше или равно 20, транзакт перейдет по ветке True (правой), иначе по ветви False (нижней).

Речь идет транзакте, который в настоящий момент проходит модуль.

Есть и другие варианты условия:

В модуле decide может проверяться:

- значение переменной (Variable);

- значение элемента массива (Variable Array 1D, Variable Array 2D);

- значение атрибута транзакта (Attribute);

- тип транзакта (Entity Type);

- произвольное выражение (expression).

Для блока Decide с типом «по условию» также возможно наличие нескольких выходов.

Немного исправим пример с грузовиками, теперь, машины с массой тонн и больше направляются по одному пути, от 10 до 20 тонн – по второму, меньше 10 тонн – по третьему.

Параметры модуля Decide показаны на рисунке:

Необходимо указать условия (они могут быть разного типа) для каждой из правых веток. Для этого используются кнопки Add, Edit, Delete. При этом будет открываться окно задания условий.

Обратим внимание на порядок условий в примере. Если бы мы поменяли их местами, а пришедший транзакт представлял бы грузовик весом тонн, то первое условие было бы выполнено (атрибут mass >= 10) и грузовик отправился бы на неверный путь. Таким образом, следует внимательно следить за порядком условий.

Рассмотрим теперь несколько примеров моделей с модулем Decide.

Пример 3. Новые работники поступают на инструктаж по технике безопасности.

После инструктажа следует небольшой тест, и если работник с ним не справляется (вероятность этого 15%), работник должен повторить инструктаж и тест снова.

Граф модели показан на рисунке:

Понятно, что модули Process с названиями Teach и Test соответствуют операциям обучения и проверке знаний. Далее следует модуль Decide, распределяющий сотрудников в зависимости от результатов теста. Не прошедшие тест сотрудники (нижняя ветка false) вновь отправляются на модуль процесса Teach.

Параметры модуля Decide:

Как видим, выбран тип «по вероятности» и указана вероятность успешного прохождения теста.

Пример 4. Студенты посещают буфет. Если студент обнаруживает, что очередь превышает 5 человек, то он уходит.

Граф модели показан на рисунке:

Структура модели очевидна. Модуль процесса buyFood соответствует покупке продуктов в буфете, и требует ресурса – продавца. Таким образом, у модуля будет очередь для студентов, ожидающих обслуживания.

Два модуля Dispose позволяют оценить, сколько студентов смогли купить себе обед (withFood), а сколько – нет (Hungry).

Рассмотрим модуль Decide с названием IsLineTooLong. Здесь выбран тип «По условию». Условием является выражение «Expression». Задано следующее логическое выражение:

NQ(buyFood.Queue) B.

Время обработки детали на станке не зависит от типа детали и составляет 7±2 минуты на станке A, 5±2 на станке B, 10±3 минут на станке С. Закон распределения равномерный.

Перемещение между станками занимает 2±1 минуты, закон распределения равномерный.

Реализовать такую модель просто. На рисунке показаны последовательности для первой и второй детали и шаги этих последовательностей.

Граф модели приведен на рисунке.

detail1Come AssignSequence detail2Come AssignSequence Два модуля Create создают транзакты-детали 2 типов. Затем в модулях Assign каждый тип детали получает последовательность.

Транзакты поступают на станцию «start» с помощью модуля Station с именем startStation. Эта станция соответствует приемной зоне цеха. Далее с помощью модуля Route деталь передают в зону того станка, который должен ее обрабатывать.

Все модули Route в модели имеют идентичные параметры.

Деталь направляется к следующей станции в соответствии со своей последовательностью, причем переход занимает от 1 до 3 минут. Например, деталь 1 после станции «stB» отправится на станцию «stC», а деталь 2 с этой же станции «stB» отправится на станцию «finish».

Модули Station отвечают за появление деталей в зоне станка. Например, как только деталь будет доставлена к станку B (станция «stB») соответствующий транзакт возникнет в модуле Station B.

После того, как деталь попадет на станцию «finish» транзакт будет выведен из модели модулем Dispose.

Для анимации станций и путей используем соответствующий элемент и прорисовываем все возможные пути.

Всего 7 учатсков: start-stA, stA-stB, stA-stC, stB-stC, stC-stB, stB-finish, StC-finish.

Теперь разместим ресурсы-станки с помощью соответствующего элемента анимации (мы использовали графическую библиотеку machines.plb).

Работа модели показана на рисунке.

Модуль Leave – это универсальный модуль, соответствующий переходу от станции к станции. Он может заменить модуль Route. В соответствии с параметрами модуля, можно указать, что переход осуществляется с помощью пути (аналогично модулю Route) или с помощью транспортера, или конвейера или требует использования ресурса (например, лифта). Также моделируется необходимая задержка во времени перед отправкой.

Аналогично модуль Enter моделирует приход транзакта на станцию, обладает расширенными характеристиками и может заменить модуль Station в начале сегмента модели.

Зачем нужно использование станций?

Как можно визуализировать перемещение транзактов между станциями?

Что такое последовательность (Sequence) для модуля Route?

Как отразить в модели тот факт, что перемещение детали между цехами занимает 5±2 минут?

6) Как создать и использовать последовательность?

7) Что делает модуль Leave?

8) Что делает модуль Enter?

9) Сколько транзактов могут одновременно перемещаться по пути между двумя 10) Может ли время перемещения между станциями быть случайным?

11) Может ли транзакт перемещаться между станциями мгновенно?

12) Что делает модуль Station?

10 Проведение имитационного эксперимента в Арена Рассмотрим пример проведения имитационного эксперимента над моделью, созданной в среде Arena.

Пример 24. Швейная фабрика имеет цех на 50 рабочих мест, которые оборудованы швейными машинками. Когда машинка выходит из строя она заменяется на резервную и передается в наладочный цех для ремонта 24.

Параметры процесса представлены в таблице.

Срок безотказной работы машинки 157 часов, закон распределения – экспоненциальный Время ремонта наладчиком швейной математическое ожидание 7, отклонение 1, Цель исследования состоит в следующем: определить оптимальный режим протекания процесса (число наладчиков и число резервных машинок).

Для принятия обоснованного решения необходимо оценить эффективность каждого варианта, сопоставив потери от простоя рабочих мест швейного цеха и затраты на заработную плату наладчиков и арендную плату за резервные машинки. Необходимо выбирать вариант, характеризующийся минимум суммарных затрат.

Данные для расчета затрат представлены в таблице.

Cуммарные затраты (C) определяем как:

Сюда входят затраты на аренду машинок С а, затраты на оплату труда наладчиков С z и потери от простоя рабочих мест С v. Все эти величины будем рассчитывать ориентируясь на один рабочий день – 8 часов.

Затраты на аренду машинок (С а ):

Это классическая задача, рассматривается в книге Шрайбер Т. Дж. Моделирование на GPSS. — М.: Машиностроение, 1980. — 592 с.

Затраты на зарплату наладчикам (С z ):

Убытки из-за простоев (С v ):

Нам неизвестна только одна величина – процент простоя рабочих мест (1-Nag). Чтобы определить Nag, загрузку рабочих мест для каждого из возможных вариантов мы можем использовать имитационную модель.

По своей природе имитационное моделирование не позволяет решать задачи оптимизации. Тем не менее, можно провести имитационный эксперимент, перебрав возможные варианты решения и выбрав наиболее эффективный.

Исследуемую систему можно представить в виде структурной схемы:

Реализуем модель в системе Arena.

В данном примере транзактом будет швейная машинка. 50+m швейных машинок будут введены в модель в момент времени 0, а затем будут циркулировать между модулями модели. То есть имеет место «замкнутая схема».

Параметры модуля Create, который введет нужное число транзактов в модель, показаны на рисунке. На рисунке значение переменной m принято равным 3.

Граф модели показан на рисунке.

После создания транзакты-машинки отправляются в швейный цех, что представлено модулем типа Process с именем Work. «Обслуживание» машинки заключается в ее эксплуатации до тех пор, пока она не сломается. Одновременно может обслуживаться до 50 машинок. Используемый в ресурс – это швея.

Очередь модуля Work имеет смысл резерва, где находятся исправные машинки. Здесь они ожидают до тех пор, пока не потребуется заменить машинку, вышедшую их строя. Если машинка выйдет из строя, а резерв будет пуст – произойдет простой рабочего места.

Вышедшие из строя машинки направляются на ремонт, который описывается модулем Process с именем Naladka. Здесь может возникнуть очередь, если наладчики будут заняты.

После окончания ремонта машинки возвращаются в швейный цех и помещаются в резерв.

Ресурсы модели:

На рисунке показан график одного из параметров системы (в данном случае среднее число занятых наладчиков). Форма графика характерна для имитационного моделирования – имеется начальный период и стационарный период, когда колебания параметра заметно уменьшаются.

Причина заключается в том, что в начале моделирования в цех поступили новые машинки, имеется полный резерв, наладчики свободны, а очередь на наладку пуста.

Для проведения расчетов нас интересует только стационарный режим.

В системе Arena можно задать так называемый разогревочный (Warm Up) период, статистика за который не собирается.

Укажем, длину периода моделирования 10000 часов, при разогревочном периоде 2000 часов.

Для моделирования при каждом варианте необходимо менять:

- мощность ресурса naladchik;

- число вводимых в модель резервных машинок в модуле Create.

В результате можно получить загрузку рабочих мест швей. Фрагмент отчета по результатам моделирования показан на рисунке.

В данном случае, загрузка составляет Nag=0.984.

На следующем этапе была проведена постановка имитационного эксперимента. Цель эксперимента – проследить поведение системы при изменении исходных данных и выбор оптимальных параметров - числа наладчиков (n) и числа резервных швейных машинок (m).

План и результаты эксперимента приведены в таблице.

Для проведения расчетов используем MS Excel.

По результатам эксперимента делаем вывод – оптимальным представляется вариант с использованием четырех наладчиков и четырех резервных швейных машинок 25.

Следующий пример относится к важному направлению – «управлению запасами». Разумеется, пример является максимально упрощенным, более реальные задачи имеют множество других деталей.

Профессиональная версия Arena включает пакет OptQuest, позволяющий автоматически проводить имитационные эксперименты с моделями и искать оптимальные решения Пример 25. Предприятие реализует своим покупателям товары со склада. Покупатели появляются приблизительно каждый час, закон распределения экспоненциальный, размер покупки составляет от 1 до 5 единиц, закон распределения равномерный. Если на складе нет достаточного объема товара – клиент уходит. Максимальная вместимость склада – 25 единиц.

Как только уровень достигает некоторой критической точки 26 (будем считать таковым 3 единицы) выполняется звонок поставщику, который доставляет необходимое число единиц продукции - до 25 штук. При этом на заказ поставщику, сборы, доставку от поставщика, разгрузку и т.д. требуется от полутора до трех часов, с наиболее ожидаемым временем – 2 часа (будем считать закон распределения равномерным). После этого товар окажется на складе и будет готов к продаже.

Стоимостные параметры:

- выручка от продажи одной единицы товара за вычетом оптовой цены – 10$ (эта же сума выступает как потери от ухода клиента);

- расходы доставку заказам (также без оптовой цены товара) – 30$.

Необходимо определить оптимальную точку перезаказа.

Построим модель в системе Arena. Предлагаемый вариант не является единственно возможным. Есть и другие способы организации системы, например с помощью модуля Signal.

В задачах управления запасами этот уровень носит название «точка перезаказа».

Прежде всего, введем переменные:

- Level – текущее число на складе. Начальное значение равно 25;

- CriticalLevel – точка перезаказа, уровень, при достижения которого делается заказ. Устанавливаем в 3, при проведении экспериментов меняем этот уровень;

- Loses – суммарные потери. Начальное значение равно 0;

- OrderCosts – затраты на обработку заказа, установлено значение 30.

Создание переменных в невизуальном модуле Variables показано на рисунке.

Для хранения информации о величине покупки каждого покупателя заведем у соответствующего транзакта атрибут demand. В случае ухода покупателя из-за отсутствия товара на складе потери составят: $10*demand (то есть 10 долларов за каждую единицу товара, который хотел приобрести клиент).

Граф модели показан на рисунке. Для наглядности все особенности расчетов показаны в виде комментариев возле блоков.