Создание и исследование имитационной модели системы массового обслуживания

Создание и исследование имитационной модели системы массового обслуживания

Введение

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

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

Целью данной курсовой работы является повышение уровня знаний в области имитационного моделирования и их практическое применение на примере использования языка GPSS World. В ходе работы будут рассмотрены теоретические основы создания модели массового обслуживания, а так же аспекты анализа ее эффективности. Полученные знания будут непосредственно применены при практической реализации проекта - создании модели, имитирующей процесс работы отдела обслуживания ЭВМ, занимающегося подготовкой носителей с программами для металлорежущих станков с числовым программным управлением.

Глава 1. Реализация задания

.1 Построение концептуальной модели

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

Для упрощения создания концептуальной модели была составлена таблица соответствий (табл. 1), определяющая аналогию между объектами модели и реальными динамическими элементами моделируемой системы.

Таблица 1. Соответствие элементов модели в GPSS реальным объектам и событиям

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

После тщательного анализа текста задания была построена следующая концептуальная модель (рис.1).

Рисунок 1. Концептуальная модель

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

.2 Блок-диаграмма модели

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

Наиболее распространенным методом описания систем является составление блок-диаграмм. Блок-диаграмма - графическое представление операций, происходящих внутри системы.

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

В случае нескольких вариантов действий от блока отходят несколько линий. Выбор логических путей может основываться на статистических или логических условиях, действующих в момент выбора. В GPSS World имеется определенное количество типов блоков для задания объектов и операций над ними. Каждому блоку соответствует графическое изображение на блок-диаграмме.

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

Рисунок 2. Блок-диаграмма модели

1.3 Листинг программы на языке GPSS

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

XPDIS Function RN1,C24

,0/.1,.104/.2,.222/.3,.335/.4,.509/.5,.69/.6,.915/.7,1.2/.75,1.38/.8,1.6

.84,1.83/.88,2.12/.9,2.3/.92,2.52/.94,2.81/.95,2.99/.96,3.2/.97,3.5

.98,3.9/.99,4.6/.995,5.3/.998,6.2/.999,7/.9998,8,,,1  Metod+,1 ;определение порядка выполнения работ

Terminate                                  (1,2,3,4)

Generate (Uniform(1,105,185)),,,3 ;поступление заявок в модель

Assign Programming,(110#FN$XPDIS) ;определение времени обработки

Assign Recording,(100#FN$XPDIS) T1,T2,T3Testing,(85#FN$XPDIS) Technological_Time,(Uniform(1,25,65)+ +P$Programming+P$Recording+P$Testing) ;определение технологического времениDirective_Time,(P$Technological_Time+C1);определение директивного времени4 Transfer ,(LL4+X$Metod) ;пересылаем транзакт в соответствую-

Link Programming,P$Technological_Time,LL1 щий блок Link (1,2,3,4)Programming,P$Technological_Time,LL1Programming,P$Directive_Time,LL1Programming,(P$Programming+P$Recording+P$Testing),LL1Seize Programming  P$Programming;имитация процесса програмирования

Release Programming E 1,X$Metod,LL5;пересылаем транзакт в соответст-

Unlink Programming,LL1,1,Back вующий блок Unlink (1 - для 1 вари-  ,LL6 анта, 2 - для 2,3,4 вариантов порядка

LL5 Unlink Programming,LL1,1 выполнения)6 Transfer ,(LL6+X$Metod) ;пересылаем транзакт в соответствую-

Link Recording,P$Technological_Time,LL2 щий блок Link (1,2,3,4)Recording,P$Technological_Time,LL2Recording,P$Directive_Time,LL2Recording,(P$Recording+P$Testing),LL2Seize Recording P$Recording ;имитация процесса записи на ЭВМ

Release Recording E 1,X$Metod,LL7;пересылаем транзакт в соответст-

Unlink Recording,LL2,1,Back вующий блок Unlink (1 - для 1 вари-  ,LL8  анта, 2 - для 2,3,4 вариантов порядка

LL7 Unlink Recording,LL2,1 выполнения)8 Transfer ,(LL8+X$Metod) ;пересылаем транзакт в соответствую-

Link Testing,P$Technological_Time,LL3  щий блок Link (1,2,3,4)Testing,P$Technological_Time,LL3Testing,P$Directive_Time,LL3Testing,P$Testing,LL3Seize Testing P$Testing;имитация процесса тестирования

Release Testing

Test E 1,X$Metod,LL9;пересылаем транзакт в соответст

Unlink Testing,LL3,1,Back вующий блок Unlink (1 - для 1 ва ,(LL9+1) рианта, 2 - для 2,3,4 вариантов по

LL9 Unlink Testing,LL3,1 рядка выполнения)

Terminate 1 ;удаление транзактов из модели

Rmult 617;фиксируем значения блока RN1

Start 3

Clear OFF;Сохраняем значения заданных величин (X$Metod=1,2,3,4)

Reset; Обнуляем значение модельного времени6173OFF6173OFF617 3

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

Далее следует блок, отвечающий за автоматический выбор вариантов упорядочивания в списках пользователя. Осуществляется это путем наращивания величины «Metod» на единицу при каждом последующем запуске. Впоследствии я обращаюсь к этой величине, определяя, в какую строку перейдет транзакт после попадания в блок «TRANSFER ,(LLi+X$Metod)», работающий в режиме безусловного перехода.

Заказы на подготовку носителей с программами (транзакты) поступают через промежутки времени, распределенные равномерно в интервале А±В (145±40 минут), после чего для них определяются следующие параметры:

1.      Programming: определение времени програмированния, Т1

2.      Recording: определение времени записи ЭВМ, Т2

3.      Testing: определение времени тестирования, Т3

4.      Technological_Time: определение технологического времени

.        Directive_Time: определение директивного времени.

После этого транзакты попадают в блок «TRANSFER», где определяется, в список с каким способом упорядочивания они попадут.

Блок «LINK» собирает транзакты из СТС и помещает их в СП. Таким образом, интерпретатор их не просматривает и не перемещает по блокам модели до тех пор, пока пользователь не возвратит их в модель.

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

Если операнд С задан, проверяется индикатор СП. Если индикатор списка установлен в положение «1», вошедший транзакт, заносится в СП в порядке, заданном операндом В. Если же индикатор списка установлен в положение «0», он переводится в положение «1», и вошедший транзакт перемещается к блоку, заданному в операнде С.

После окончания обработки транзакт попадает в блок «TEST», параметры которого заданны таким образом, что если транзакт был в списке, упорядочивание в котором происходит первым способом, то он попадет в следующий по порядку блок, «UNLINK». Блок «UNLINK» удаляет транзакты из СП. После этого интерпретатор GPSS возобновляет их движение по модели. Операнд А задает СП, из которого удаляются один или несколько транзактов. В операнде В указывается номер блока, к которому переходят удаляемые из списка транзакты (в нашем случае это метка). Операнд С задает число транзактов, удаляемых из СП (счетчик удалений).

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

Если список не пуст, вычисляется значение операнда С (счетчика удалений), определяющего число транзактов, удаляемых из списка. Транзакты удаляются, начиная с первого в списке до тех пор, пока значение счетчика удалений не станет равным нулю, или пока не будут исчерпаны все транзакты из списка. Удаленные из СП транзакты будут помещены в СТС и направлены к блоку, номер которого указан в операнде В. Транзакт, вошедший в блок UNLINK, перемещается к следующему по номеру блоку. Если в параметре D указано значение «BACK», то выборка из списка осуществляется с конца.

После блока «UNLINK» транзакт переходит к следующему этапу реализации заявки - записи, после нее - к тестированию и покидает систему. Алгоритм выполнения обработки на всех трех устройствах аналогичен и не требует повторного описания. Единственное различие между этапами выполнения заключается во времени обработки.

Установив значение команды «CLEAR» в положение «OFF», мы сохраним значение величины «Metod=1», соответственно при следующем запуске ее значение станет равно двум и реализуется второй вариант упорядочивания в списке, и т.д. Команда «RESET» сбрасывает счетчик модельного времени, что в свою очередь необходимо для корректного определения директивного времени.

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

.4 Результаты моделирования

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

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

В результате прогона модели были получены следующие результаты:

1.      Сначала выполняются те заказы, которые имеют самое большое технологическое время выполнения:

FACILITY ENTRIES UTIL. AVE. TIME AVAIL. OWNER PEND INTER RETRY DELAY3 0.486 129.743 1 0 0 0 0 03 0.281 75.064 1 0 0 0 0 03 0.163 43.499 1 0 0 0 0 0CHAIN SIZE RETRY AVE.CONT ENTRIES MAX AVE.TIME0 0 0.102 1 1 81.9260 0 0.081 1 1 64.7220 0 0.006 1 1 5.177RETRY VALUE

METOD 0 1.000

.        Сначала выполняются те заказы, которые имеют самое маленькое технологическое время выполнения:

FACILITY ENTRIES UTIL. AVE. TIME AVAIL. OWNER PEND INTER RETRY DELAY3 0.486 129.743 1 0 0 0 0 03 0.281 75.064 1 0 0 0 0 03 0.163 43.499 1 0 0 0 0 0CHAIN SIZE RETRY AVE.CONT ENTRIES MAX AVE.TIME0 0 0.102 1 1 81.9260 0 0.081 1 1 64.7220 0 0.006 1 1 5.177RETRY VALUE

METOD 0 2.000

.        Сначала выполняются те заказы, которые имеют наименьшее оставшееся время обработки:

FACILITY ENTRIES UTIL. AVE. TIME AVAIL. OWNER PEND INTER RETRY DELAY3 0.486 129.743 1 0 0 0 0 03 0.281 75.064 1 0 0 0 0 03 0.163 43.499 1 0 0 0 0 0CHAIN SIZE RETRY AVE.CONT ENTRIES MAX AVE.TIME0 0 0.102 1 1 81.9260 0 0.081 1 1 64.7220 0 0.006 1 1 5.177RETRY VALUE

METOD 0 3.000

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

FACILITY ENTRIES UTIL. AVE. TIME AVAIL. OWNER PEND INTER RETRY DELAY3 0.486 129.743 1 0 0 0 0 03 0.281 75.064 1 0 0 0 0 03 0.163 43.499 1 0 0 0 0 0CHAIN SIZE RETRY AVE.CONT ENTRIES MAX AVE.TIME0 0 0.102 1 1 81.9260 0 0.081 1 1 64.7220 0 0.006 1 1 5.177RETRY VALUE

METOD 0 5.000

Сравнив отчеты, сгенерированные для четырех вариантов данной задачи мы видим, что данные идентичны. Подтверждает это и информация, полученная из журнала:

/06/11 05:52:09 Simulation in Progress.

05/06/11 05:52:09 The Simulation has ended. Clock is 800.106481.

/06/11 05:52:09 Reporting in Курсовой_Exelent.52.1 - REPORT Window.

/06/11 05:52:09 Simulation in Progress.

/06/11 05:52:09 The Simulation has ended. Clock is 800.106481.

/06/11 05:52:09 Reporting in Курсовой_Exelent.52.2 - REPORT Window.

/06/11 05:52:10 Simulation in Progress.

/06/11 05:52:10 The Simulation has ended. Clock is 800.106481.

/06/11 05:52:10 Reporting in Курсовой_Exelent.52.3 - REPORT Window.

/06/11 05:52:10 Simulation in Progress.

/06/11 05:52:10 The Simulation has ended. Clock is 800.106481.

05/06/11 05:52:10 Reporting in Курсовой_Exelent.52.4 - REPORT Window.

Параметр D=3 в блоке «GENERATE» был задан для того, чтобы все сгенерированные в модели заявки были обработаны, в противном же случае установить истинные значения параметров загрузки будет невозможно. Время обработки трех заявок составило примерно 800 минут.

.5 Обработка результатов моделирования

На основании полученных данных мы можем сделать вывод, что эффективность системы не зависит от порядка выполнения ожидающих в очереди заказов при небольшом количестве заявок. Объясняется это тем, что время обработки на первом этапе больше, чем на втором, на втором - больше чем на третьем. Таким образом, вероятность возникновения очереди крайне мала. Для повышения эффективности системы необходимо увеличить число заявок, поступающих в систему. Установив параметр блока GENERATE «D=100» мы видим, что нагрузка на устройства возросла, и списки пользователей используются более активно:

FACILITY ENTRIES UTIL. AVE. TIME AVAIL. OWNER PEND INTER RETRY DELAY100 0.674 105.110 1 0 0 0 0 0100 0.650 101.342 1 0 0 0 0 0100 0.565 88.129 1 0 0 0 0 0CHAIN SIZE RETRY AVE.CONT ENTRIES MAX AVE.TIME0 0 0.544 48 5 176.8240 0 1.451 63 8 359.3470 0 1.666 54 12 481.318RETRY VALUE0 1.000

_____________________________________________________________ENTRIES UTIL. AVE. TIME AVAIL. OWNER PEND INTER RETRY DELAY100 0.673 105.110 1 0 0 0 0 0100 0.649 101.342 1 0 0 0 0 0100 0.564 88.129 1 0 0 0 0 0CHAIN SIZE RETRY AVE.CONT ENTRIES MAX AVE.TIME0 0 0.449 48 3 146.2940 0 0.749 63 5 185.8330 0 0.449 45 4 155.852RETRY VALUE0 2.000

_____________________________________________________________ENTRIES UTIL. AVE. TIME AVAIL. OWNER PEND INTER RETRY DELAY100 0.671 105.110 1 0 0 0 0 0100 0.647 101.342 1 0 0 0 0 0100 0.562 88.129 1 0 0 0 0 0CHAIN SIZE RETRY AVE.CONT ENTRIES MAX AVE.TIME0 0 0.475 48 3 154.9880 0 0.973 63 6 242.0520 0 0.639 52 6 192.468RETRY VALUE0 3.000 ENTRIES UTIL. AVE. TIME AVAIL. OWNER PEND INTER RETRY DELAY100 0.676 105.110 1 0 0 0 0 0100 0.652 101.342 1 0 0 0 0 0100 0.567 88.129 1 0 0 0 0 0CHAIN SIZE RETRY AVE.CONT ENTRIES MAX AVE.TIME0 0 0.545 48 5 176.5320 0 1.530 63 8 377.5800 0 0.506 54 5 145.706RETRY VALUE0 4.000

/06/11 06:35:03 Model Translation Begun.

/06/11 06:35:03 Ready.

/06/11 06:35:03 Simulation in Progress.

/06/11 06:35:03 The Simulation has ended. Clock is 15599.342359.

/06/11 06:35:03 Reporting in Курсовой_Exelent.53.1 - REPORT Window.

/06/11 06:35:03 Simulation in Progress.

/06/11 06:35:03 The Simulation has ended. Clock is 15626.228919.

/06/11 06:35:03 Reporting in Курсовой_Exelent.53.2 - REPORT Window.

/06/11 06:35:04 Simulation in Progress.

/06/11 06:35:04 The Simulation has ended. Clock is 15667.801467.

/06/11 06:35:04 Reporting in Курсовой_Exelent.53.3 - REPORT Window.

/06/11 06:35:04 Simulation in Progress.

/06/11 06:35:04 The Simulation has ended. Clock is 15545.055376.

/06/11 06:35:04 Reporting in Курсовой_Exelent.53.4 - REPORT Window.

Таблица 2. Зависимость выходных данных от числа транзактов, вошедших в систему

.

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

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

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

Заключение

программа модель имитационный

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

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

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

Библиографический список

1.  Боев В.Д. Моделирование систем. Инструментальные средства GPSS. - СПб: БХВ-Петербург, 2010. - 368 с.

2.  Томашевский В., Жданова E. Имитационное моделирование в среде GPSS. - М.:Бестселлер, 2007. - 416 c.

3.      Тынченко В.С. Имитационное моделирование экономических процессов/ Конспект лекций. - Красноярск, 2011. - 488 c.

.        Советов Б.Я., Яковлев С.А. Моделирование систем. Практикум: Учеб. пособие для вузов по спец. «Автоматизир. системы обработки информ. и упр.». - М.: Высш. шк., 2009. - 224 с.