Модель функционирования терминала

Событийная часть модели

Объекты событийной части модели показаны на рис. 7.3.

Для построения использованы следующие двадцать объектов библиотеки Enterprise Library (в скобках после имени каждого объекта указано их количество в событийной части модели):

• source (один);
• queue (восемь);
• delay (восемь);
• split (один);
• match (один);
• sink (один).

Создадим событийную часть модели. Для неё мы уже создали область присмотра с именем Модель_Терминал и перетащили элемент Прямоугольник, в котором и разместим все элементы.

1. Перетащите объект source. Установите его свойства согласно табл. 7.2.
2. Создайте нестандартный класс заявки Car с полями:

   int id;
   double vxod;

Дополнительное поле id нестандартного класса заявки Car введено для проверки объектом match условия объединения двух заявок в одну.

Поле vxod предназначено для записи времени входа заявки в модель. И в последующем для вычисления времени обработки заявки, хотя можно было бы обойтись и без этого поля, а использовать объект TimeMeasureStart вместе с TimeMeasureEnd для определения того же времени.

Перетащите остальные объекты, соедините так, как показано на рис. 7.3. Последовательно выделяя эти объекты, установите их свойства согласно табл. 7.3.

увеличить изображение
Рис. 7.3. Элементы модели Terminal

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

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

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

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

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

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