Файл: Конспект лекций Для студентов специальности 080801. 65 - приклад.doc

Описание процесса использования ресурса требованием целесо­образно разбить на три подпрограммы.

Первая - это ЗАПРОС-НАЗНАЧЕНИЕ ресурса R требованию j (в языке GPSS этой подпрограмме соответствует блок SEIZE). Алго­ритм ее работы следующий:

1. Если ресурс R (ПРОДАВЕЦ) может быть сразу назначен тре­бованию j, то изменить состояние ресурса R на «занятый». Запомнить момент начала обслуживания требования t_j.₊₁^н. Передать управление подпрограмме ОБСЛУЖИВАНИЕ требования j.

2. Если ресурс R занятый, то поставить требование j в ОЧЕРЕДЬ к ресурсу R.

Вторая подпрограмма - ОБСЛУЖИВАНИЕ требования j (в язы­ке GPSS этой подпрограмме соответствует блок ADVANCE). Ее ал­горитм работы очень простой - определить событие «конец обслужи­вания требования j» как t_j^K = t_j^H + t_j^об (где t_j^об - время обслуживания в устройстве). Т.е. создается уведомление о событии в СБС для переда­чи управления подпрограмме освобождения ресурса R требованием j.

Третья подпрограмма - ОСВОБОЖДЕНИЕ ресурса R требова­нием j (в языке GPSS этой подпрограмме соответствует блок RELEASE). Алгоритм ее работы следующий.

1. Изменить состояние ресурса R (ПРОДАВЕЦ) на «свободный». Передать управление подпрограмме УНИЧТОЖЕНИЕ требования.

2. Проверить, есть ли требования в ОЧЕРЕДИ к ресурсу R? Если есть, то выбрать требование из ОЧЕРЕДИ и запланировать для него событие ЗАПРОС-НАЗНАЧЕНИЕ ресурса R.

Подпрограмма УНИЧТОЖЕНИЕ требования (в языке GPSS этой подпрограмме соответствует блок TERMINATE) необходима для уничтожения структуры данных каждого требования. Если тре­бования не уничтожать, то со временем они переполнят память ком­пьютера.

Кроме перечисленных подпрограмм необходима программа управления процессом моделирования (ПУМ), которая запускает процесс моделирования и отслеживает движение каждого требования па модели путем вызова названных подпрограмм обработки событий. Другое назначение этой программы - вести список упорядоченных во времени событий СБС и продвигать ЧАСЫ модельного времени от события к событию. В языке GPSS функции ПУМ выполняет про­грамма-интерпретатор (транслятор).

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

Планирование будущего события означает, что в момент начала действия его продолжительность вычисляется или определяется (на­пример, из заданного статистического распределения), чтобы устано­вить время конца действия и занести это событие вместе с его време­нем в СБС. В реальном мире большинство будущих событий не на­мечено, они просто происходят (как, например, случайные поломки оборудования или случайные поступления покупателей). В модели такие случайные события представлены концом некоторого действия, которое запланировано на будущее модельное время.

В любое данное время моделирования t^м СБС содержит все предварительно намеченные будущие события и связанные с этими событиями времена t₁^м , t₂^м, ... . В СБС события упорядочены в хро­нологическом порядке по времени, то есть времена событий удовле­творяют условиям

Время t^м значения ЧАСОВ - текущее значение времени моде­лирования. Событие, связанное со временем t₁^м, называется пред­стоящим событием, то есть это следующее событие, которое про­изойдет. После того, как отображающие состояния системы ЧА­СЫ =t^м во время моделирования были модифицированы, ЧАСЫ продвигаются ко времени моделирования ЧАСЫ= t₁^м, предстоящее намеченное событие удаляется из СБС и выполняется подпрограмма события. Выполнение подпрограммы предстоящего события означа­ет, что отображено новое состояние системы в течение времени t₁^м, которое создано на основании старого состояния модели во время t^м и характера предстоящего события. Во время t₁^м новые будущие со­бытия могут произойти или не произойти, но если любые из них на­мечены, то создаются намеченные события и помещаются в соответ­ствующие позиции в СБС. После того, как новое отображение со­стояния системы в течение времени t₁^м было модифицировано, ЧАСЫ продвигаются ко времени нового предстоящего события, и выполняется подпрограмма этого события. Такой процесс повторяет­ся до окончания имитации. На рис. 1.4 показана структурная схема имитационной модели.

В момент начала моделирования (время моделирования t₀^м = 0) ПУМ передает управление подпрограмме ГЕНЕРАТОР, которая оп­ределяет момент прихода первого покупателя и намечает событие ЗАПРОС-НАЗНАЧЕНИЕ ресурса R в СБС на время t_}^м =t₁^BX. Так как больше событий в системе нет, то ЧАСЫ переводятся на значение времени t₁^м вызывается подпрограмма ГЕНЕРАТОР и подпрограмма ЗАПРОС-НАЗНАЧЕНИЕ ресурса R.

Подпрограмма ГЕНЕРАТОР определяет будущее событие (мо­мент прихода второго покупателя t₂^ВХ) и намечает это событие в СБС на время t₂^ВХ .

Подпрограмма ЗАПРОС-НАЗНАЧЕНИЕ проверяет состояние ресурса (ПРОДАВЦА). Так как ресурс R свободный, то он назначает­ся первому покупателю и состояние ресурса R изменяется на «заня­тый». Запоминается момент начала обслуживания требования t₁^н. Пе­редается управление подпрограмме ОБСЛУЖИВАНИЕ покупателя 1.

Подпрограмма ОБСЛУЖИВАНИЕ определяет событие конца обслуживания покупателя 1, как t₁^K = t₁^H + t₁^об, т.е. создается уведомле­ние о будущем событии в СБС для передачи управления подпро­грамме ОСВОБОЖДЕНИЯ ресурса R требованием 1 на время t₁^к.

Таким образом, в СБС имеется два элемента - один с намечен­ным событием появления покупателя 2 на время t₂^ВХ, а второй с наме­ченным событием окончания обслуживания покупателя 1 на время t₁ ^K. Если время t₂^ВХ < t₁ ^K, то ЧАСЫ будут переведены на время t₂^М = t₂^ВХ, т. е. снова будет вызвана подпрограмма ГЕНЕРАТОР и сгенерирова­но появление покупателя 2. В этот же момент времени t₂^м произойдет вызов подпрограммы ГЕНЕРАТОР, которая наметит в СБС появле­ние покупателя 3 на время t₃^ВХ и вызов подпрограммы ЗАПРОС-НАЗНАЧЕНИЕ ресурса R, но так как ресурс занят обслуживанием покупателя 1, то покупатель 2 будет поставлен в очередь к ресурсу R.

В СБС снова окажутся два элемента - один для намеченного со­бытия появления покупателя 3 на время t₃^BX, а второй с намеченным событием окончания обслуживания покупателя 1 на время t₁^k. Если время t₃^вх >t₁^k, то ЧАСЫ будут переведены на время t₃^м=t₁^K, т, е. бу­дет вызвана подпрограмма ОСВОБОЖДЕНИЕ ресурса R покупате­лем 1. Она изменить состояние ресурса R (ПРОДАВЕЦ) на «свободный и передаст управление подпрограмме УНИЧТОЖЕНИЕ требования. Затем проверит, есть ли требования в ОЧЕРЕДИ к ресурсу R, и выберет покупателя 2 из ОЧЕРЕДИ, наметив для него событие для подпрограммы ЗАПРОС-НАЗНАЧЕНИЕ ресурса R.

Вызванная в это же модельное время t₃^м подпрограмма УНИЧТОЖЕНИЕ разрушит структуру данных (удалит ссылку на ад­рес) для покупателя 1. Эта же подпрограмма при необходимости мог­ла бы вычислить время пребывания покупателя 1 в системе, как t₃^пр = t_З^м – t₁^bx , для дальнейшей статистической оценки времени пребыва­ния покупателей в системе.

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

Остается открытым вопрос об окончании процесса моделирова­ния. Возможны три варианта:

1. Через модель пройдут все покупатели, сгенерированные ГЕНЕРАТОРОМ, например, 100 покупателей. В этом случае в СБС после обслуживания последнего, сотого, покупателя не будет ни од­ного намеченного события.

2. Если поток покупателей от генератора не ограничен (напри­мер, генерируется неограниченный пуассоновский поток), то модели­рование можно закончить после прохождения через модель опреде­ленного количества покупателей, например, 1000. Для этого в под­программе УНИЧТОЖЕНИЕ надо поставить счетчик покупателей и прекратить моделирование после 1000 покупателей. В языке GPSS такой счетчик организуется в команде START, которая начинает про­цесс моделирования.

3. Необходимо промоделировать работу системы в течение за­данного периода времени, например, 480 мин. В этом случае можно при каждом продвижении ЧАСОВ модельного времени t^м проводить сравнение текущего времени со значением 480. Как только значение модельного времени будет больше или равно 480, необходимо пре­кратить моделирование. Однако такой способ неудачный, так как может сильно замедлить работу модели из-за проверки условия. По­этому обычно поступают следующим образом. Генерируют специ­альное требование-таймер с помощью еще одной подпрограммы ГЕНЕРАТОР с намеченным временем входа в модель t^BX = 480. Тре­бование-таймер после генерации сразу же направляется в еще одну подпрограмму УНИЧТОЖЕНИЯ, в которой ставят счетчик требова­ний на единицу. По этому счетчику прекращают моделирование. В этом случае в СБС будет все время находиться элемент для требова­ния-таймера со временем наступления события 480. Как только это событие станет предстоящим намеченным, ЧАСЫ будут переведены на время 480 и моделирование прекратится.

В процессе моделирования обычно собирается статистическая информация о работе модели при каждом продвижении ЧАСОВ мо­дельного времени. Такой информацией может быть величина очере­ди, время пребывания в очереди и устройстве обслуживания, загрузка устройства, состояние прибора и другие параметры. Для сбора этой информации обычно создается подпрограмма ВЫБОРОЧНЫЙ ИЗМЕРИТЕЛЬ, которая накапливает ее и по окончании моделирова­ния выдает стандартный статистический отчет. В языке GPSS такая статистическая информация накапливается в системных числовых атрибутах (СЧА) и доступна в процессе моделирования только на считывание. Доступ к СЧА дает возможность управлять процессом движения требований, например, ограничивать размер или время на­хождения в очереди.

В этой главе даны основы организации моделирования на при­мере простой СМО. В языке GPSS обычно используются более слож­ные алгоритмы, описанные в параграфе 4.22.