мод сис / V.Boev-GPSSvsAnyLogic

341

342

Поясним необходимость и целесообразность применения некоторых объектов. В модели заявка имитирует транспорт. Объект split предназначен для расщепления одной заявки в нашей модели на две заявки. Одна поступает, как документ, в зону Z, а вторая, как транспорт, продолжает движение. Когда в зоне Z необходимые для обработки транспорта действия выполнены (подготовлены документы), объект match фиксирует этот момент, то есть синхронизирует дальнейшее движение транспорта. Вторая заявка направляется в объект sink и уничтожается. Как известно, объединить две заявки в одну (а значит не использовать объект sink) можно с помощью объекта combine. Однако в нашем случае combine использовать нельзя, так как он не проверяет выполнение у заявок условий, необходимых для их уничтожения. Поэтому могут быть объединены различные заявки. Объект match проверяет условия объединения, установленные в нашем случае разработчиком модели в дополнительном поле id нестандартного класса заявки Car (entity1.id == entity2.id), именно двух заявок в одну. То есть синхронизации движения заявки как документа и заявки как автомобиля при применения объекта combine не обеспечивается.

В табл. 7.4 указаны свойства объекта sink.

343

Таблица 7.4

Остановимся на коде свойства Действие при входе. Заявки с выхода 1 объекта match можно было бы не направлять на этот объект sink, а добавить еще объект sink и уничтожать их там. Но у нас ознакомительная версия, которая не позволяет иметь в модели на диаграмме одного класса больше двадцати объектов (в образовательной версии это возможно). Нам не хватило ровно одного объекта, поэтому пришлось поступить так (размещать объекты на разных диаграммах ради этого мы посчитали нецелесообразным). Для реализации такого приема на выходе 1 объекта match entity.id = 0, то есть поле id обнуляется и все заявки с таким полем игнорируются. Но в количестве заявок, вошедших в объект sink, они учитываются. Поэтому пришлось для счета количества обработанных транспортов ввести переменную kolJ, хотя имеется стандартная функция count(), которая возвращает количество заявок, вошедших в данный объект. Любых заявок, без какого-либо их разделения.

344

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

Результаты проведенных нами на построенных моделях экспериментов сведены в табл. 7.5. В этот раз мы выполнили по одному эксперименту на каждой модели. В GPSS-модели начальные числа генераторов случайных чисел устанавливали произвольно, а в AnyLoic-модели установили число 1876. В GPSS World выполнили 10 000 прогонов, а в AnyLogic увеличили время моделирования в 10 000 раз, то есть моделировали в течение 4 800 000 мин.

Как видно, результаты моделирования идентичны. Кроме машинного времени, которое в GPSS World составляет 25 мин 34 с, то есть примерно в 65 раз больше, чем в AnyLogic. Различие в количестве обработанных в течение 8 часов автомобилей (KolObrCar) и среднего времени обработки одного автомобиля (TimeObr) незначительно. Коэффициенты использования элементов терминала и максимальные длины очередей к ним одинаковые.

7.3. Эксперименты

Далее поступим так. Проведем эксперименты с моделями в

GPSS World и AnyLogic. В GPSS World это будет дисперсионный анализ, а в AnyLogic — оптимизация стохастических моделей. В результате мы получим оптимальные значения факторов и показатели функционирования терминала, которые и оценим.

345

7.3.1. Первый отсеивающий эксперимент в GPSS World

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

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

1.Запустите GPSS World. Откройте модель Terminal. Выбе-

рите Edit / Insert Experiment / Screening … (Правка / Вставить эксперимент / Отсеивающий …). Откроется диалоговое окно

Screening Experiment Generator (Генератор отсеивающего экс-

перимента). Приступите к заполнению полей диалогового окна.

2.В поля Experiment Name (Имя эксперимента) и Run

Procedure Name (Имя процедуры запуска) введите, например,

Terminal и RunTerminal соответственно (рис. 7.4). Имена эксперименту и процедуре запуска эксперимента дает пользователь.

3.Введите ранее выбранные согласно стратегическому планированию эксперимента факторы (табл. 7.6), начиная с фактора А. В поле Name (User Variable) (Имя (Переменная пользовате-

ля)) введите имя фактора, в поля Value1 и Value2 — его нижний и верхний уровни соответственно. Запомните соответствие между факторами и именами переменных.

4.Ниже идет группа Fraction (Часть полного эксперимен-

та). Установите Full, что соответствует полному факторному эксперименту. Справа под Run Count появится число 64, так как

26 64 . Это число наблюдений, которое нужно сделать в эксперименте. Количество прогонов в каждом наблюдении определим позже при тактическом планировании эксперимента.

346

Рис. 7.4. Диалоговое окно (заполненное) Screening Experiment Generator (Генератор отсеивающего эксперимента)

5. В поле Expression (Выражение) группы Result (Резуль-

тат) введите выражение, по которому вычисляется время обработки одного автомобиля: X$TimeSum/N$KolObr.

6. После группы Result (Результат) расположены два флажка, позволяющие выбирать опции. При выборе опции Generate Run Procedure вместе с экспериментом создается стандартная процедура запуска, которую пользователь может корректировать согласно своим требованиям. Выбор второй опции Load F11 with CONDUCT Command закрепляет команду CONDUCT за функциональной клавишей F11. Тогда после создания объекта «Процесс моделирования» для запуска эксперимента нужно только нажать функциональную клавишу F11. Выберите обе опции.

347

7.Создайте Plus – операторы и вставьте их в нижнюю часть модели Terminal. Для этого нажмите кнопку Insert Experiment (Вставить эксперимент), расположенную в левой нижней части диалогового окна Screening Experiment Generator (Генератор отсеивающего эксперимента) (см. рис. 7.4). Так как была выбра-

на опция Generate Run Procedure, то создана стандартная процедура запуска.

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

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

цедуры запуска. Там в разделе Set up your own run conditions (За-

дайте свои условия наблюдения) имеются две команды START,

между которыми находится команда RESET (рис. 7.5). Поясним назначение этих команд.

9.Первой командой START

DoCommand(―START 100,NP‖); /*Get past the Startup Period. */

определяется количество прогонов в неустоявшемся режиме. Команда RESET сбрасывает в ноль накопленную в этом режиме статистику без удаления транзактов из процесса моделирования.

10. Второй командой START

DoCommand(―START 1000,NP‖);/*Run the Simulation. */

определяется количество прогонов в одном наблюдении. В обеих командах используется операторNP — стандартный отчѐт не выводится. На рис. 7.5 показаны условия стандартной процедуры за пуска после корректировки. Обе команды START мы оставили без изменения, а вот после команды RESET вставили строку

DoCommand(―SAVEVALUE TimeSum,0‖);/*Run the Simulation. */

которая обнуляет ячейку TimeSum.

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

11. После корректировки процедуры запуска нажмите Ok. Сгенерированный код Plus – эксперимента появится ниже программы GPSS-модели.

348

Рис. 7.5. Условия стандартной процедуры запуска после корректировки

12. Проведите трансляцию, т. е. создайте объект «Процесс моделирования», для чего выполните команду Command / Create Simulation (Команда / Создать процесс моделирования).

Рис. 7.6. Окно Journal (Журнал) с сообщением

об успешном создании объекта «Процесс моделирования»

349

13.При отсутствии ошибок в сгенерированном эксперименте в окне Journal (Журнал) появится сообщение (см. рис. 7.6).

14.Запустите эксперимент. Для вызова эксперимента предназначена команда CONDUCT. Ранее за функциональной клавишей

[F11] была закреплена команда CONDUCT (Edit/Settings/Function Keys (Правка/Настройки /Функциональные клавиши)) выбо-

ром соответствующей опции (см. рис. 7.4). Нажмите функциональную клавишу [F11]. Эксперимент начинает работать.

15.В ходе выполнения эксперимента автоматически создается отчет, который по готовности записывается в окно Journal (Журнал) объекта «Процесс моделирования». В отчете содержатся Yield — целевая функция, значения еѐ и значения факторов, при которых получены эти значения целевой функции.

16.Фрагмент отчѐта для четырех наблюдений (Run33 … Run36) показан на рис. 7.7. К этим данным и условиям выбора именно этого фрагмента отчѐта мы обратимся позднее.

17.В результате дисперсионного анализа определяется также среднее время обработки одного автомобиля при 64 комбинациях выбранных значений факторов (см. табл. 7.8). В данном случае это время составляет 44,962 мин, то есть около 45 мин.

Рис. 7.7. Окно Journal (Журнал) с отчѐтом первого эксперимента

18. Сохраните эксперимент, указав имя DispTerminalTimeObr.

350