logo search

3.2.2. Предварительный анализ модели

Созданная нами модель готова для использования. Перейдём к её отладке. Зададим в меню Run параметры работы модели в соответствии с заданными условиями. Для этого на вкладке Replication Parameters окна Run Setup установим значение параметра Replication Length – 10. Остальные параметры оставим без изменения. Запустим модель на счёт. Если моделирование завершилось выводом запроса на предоставление отчёта (рис. 3.7), то это уже обнадёживающий результат, показывающий, что модель, по крайней мере, работает. Если при составлении модели или при заполнении диалоговых окон была допущена ошибка, то может появиться окно, сообщающее об ошибке компиляции или счёта и предоставляющее анализ её возможных причин. Более коварными являются ошибки, не приводящие к прерыванию компиляции или исполнения программы. Об их наличии можно судить по несуразностям в предоставляемом отчёте о работе.

Будем считать, что мы не допустили явных ошибок, программа была скомпилирована, расчет закончен и отчёт о работе предоставлен. Рассмотрим его внимательнее (рис. 3.18). Мы видим, что в окне проекта развернулась вкладка Reports, в которой мы можем выбрать категории, по которым будет предоставляться отчёт. По умолчанию выводится обзор категорий (Category Overview).

В средней части экрана находится каталог отчёта. Ветви этого каталога можно раскрывать и сворачивать щелчком левой клавиши мыши на пиктограммах точек ветвления. Как видно из рис. 3.18, основными категориями отчёта являются объекты (Entity), очереди (Queue) и ресурсы (Resource). Движение объектов в системе и очереди характеризуются временными (Time) и другими (Other) параметрами. Среди временных параметров: полезное время (Value Added (VA) Time), непроизводительно потраченное время (Non Value Added (NVA) Time), время ожидания (Wait Time), время перемещения (Transfer Time), время пребывания в системе (Total Time) и разное другое время (Other Time). Среди других параметров, характеризующих объекты: число объектов, поступивших в систему (Number In) за время счёта, число объектов, покинувших систему (Number Out) и число объектов одновременно находящихся в системе (Work in Process (WIP)).

Рис. 3.18. Отчёт о результатах моделирования

Параметрами очередей являются время ожидания (Waiting Time) и число объектов (Number Waiting) в каждой очереди. Параметрами, характеризующими ресурсы, являются (мгновенный) коэффициент утилизации ресурса (Instantaneous Utilization), количество занятых единиц ресурса (Number Busy), назначенное число ресурсов (Number Scheduled), коэффициент утилизации ресурса, согласно расписанию (Scheduled Utilization), и полное количество задействованных единиц ресурса (Total Number Seized). Конкретные цифры, представленные в отчётах, полученных разными операторами, могут различаться вследствие статистического характера вычислений, но они должны иметь некоторое сходство и быть правдоподобными. Первый этап анализа, как раз, и заключается в оценке правдоподобности полученных результатов.

Прежде всего, обратим внимание на верхнюю строчку первой страницы отчёта (рис. 3.18), где сказано, что была выполнена одна репликация (прогон программы) и единица измерения времени – час. Дальше мы можем найти, что из системы вышло 60 объектов (клиентов). Сравним это с тем, что можно было бы ожидать. Для этого посмотрим расписание ArrivalSchedule (рис. 3.16). В соответствии с ним в первый час в среднем должно прибыть пять клиентов, во второй час шесть и т.д. В сумме должно быть: 5+6+8+10+10+10+9+7+5+3=73 клиента – число, близкое к шестидесяти. Пожалуй, можно считать это правдоподобным результатом.

Рассмотрим теперь временные параметры, характеризующие объекты в системе. В отчёте мы видим четыре значения, соответствующие каждому времени (рис. 3.19): среднее (Average), полуширину функции распределения средних значений (HalfWidth), минимальное значение (Minimum Value) и максимальное значение (Maximum Value). Полезным временем у нас считается время обслуживания клиента парикмахером потому, что в блоке Process в графе Allocation в модели установлена опция Value Added.

Рис. 3.19. Временные характеристики в окне отчёта

Минимальное значение полезного времени − 0.078 часа, или 4.68 минут, больше, чем минимальное установленное нами время обслуживания клиента (4 минуты). Максимальное время обслуживания 0.22 часа или 13.2 минуты меньше, чем наибольшее возможное время обслуживания (14 минут). Среднее время находится между указанными значениями. Полуширина незначительна (Insufficient) в связи с тем, что была сделана только одна репликация. Непроизводительные и «другие» затраты времени равны нулю потому, что в нашей системе никакой вид времени не отнесён в эти разряды. Минимальное время ожидания равно нулю, это значит, что хотя бы один клиент не ждёт в очереди. Максимальное время ожидания − 1.27 часа и среднее время ожидания − 0.67 часа. Времени переноса в нашей системе нет. Среднее и максимальное значения полного времени, проведенного клиентом в парикмахерской, превышают аналогичные показатели других временных характеристик, что вполне объяснимо, как и равенство минимальных значений полного времени и полезного времени. Все числа пока кажутся разумными.

На третьей странице отчёта, предоставляемого Arena, (рис. 3.20), можно найти следующие данные. Минимальное число клиентов в парикмахерской – 0, а максимальное – 12. В обоих случаях минимальное и максимальное значения – целые числа, как это и должно быть. Время ожидания в единственной очереди такое же, как и полное время ожидания в системе. Здесь надо отметить, как составляются названия очередей, образующихся в системе: из названия блока, в котором возникает очередь, и следующего через точку слова Queue (Очередь). В данном случае мы имеем единственную очередь HairCut.Queue.

Рис. 3.20. Отчёт о результатах моделирования

На последней странице отчёта мы находим данные об использовании ресурсов (рис. 3.21). Мгновенный коэффициент использования ресурса может быть либо ноль, либо единица (парикмахер либо занят, либо свободен). Коэффициент использования ресурса определяется как среднее по времени от мгновенного коэффициента. Количество занятых в данный момент парикмахеров равно либо нулю (минимум), либо единице (максимум). Средние значения в обоих случаях совпадают. Плановое использование ресурса – 1, так как оно установлено равным единице в единственном блоке модели, который использует ресурс. Так как каждая стрижка производится согласно расписанию, величина Scheduled Utilization оказывается равной среднему числу занятых парикмахеров (Number Busy). Полное число захватов единицы ресурса (Total Number Seized) равно количеству прошедших клиентов потому, что каждый из них был обслужен единственным парикмахером.

Рис. 3.21. Отчёт об использовании ресурсов

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

Для начала в окне Run Setup увеличим число прогонов модели до 10 и изменим единицы измерения времени (Base Time Units) на минуты. Посмотрим в отчёте, к каким изменениям это привело. Значение характерного времени стало выражаться в минутах. Каждое характерное время представлено теперь шестью значениями (рис. 3.22). К четырём рассмотренным ранее добавились минимальное и максимальное значение среднего. Полуширина распределения средних значений величин теперь не равна нулю. Обратите внимание, что среднее значение входящих в систему клиентов (69) больше, чем выходящих (61). Это значит, что часть клиентов остаётся в парикмахерской после её закрытия. Такого быть не должно. Нам нужно будет модифицировать модель так, чтобы все вошедшие клиенты выходили из системы.

Рис. 3.22. Временные характеристики в окне отчёта

Сделаем теперь так, чтобы в систему попадали только объекты одного типа. Для этого в блоке Decide в поле Percent True нужно ввести 100. После завершения счёта мы можем увидеть в отчёте, что минимальное, среднее и максимальное значения полезного времени стали близки к за­данным в блоке Assign параметрам функции треугольного распре­деления: 4, 6 и 8 минут соответственно. Время ожидания и пребывания в системе существенно уменьшилось. Среднее полезное время, коэффициент ути­лизации и число клиентов в очереди тоже уменьшаются. Все показатели ведут себя предсказуемым образом, что говорит о правильности работы модели.

Восстановим теперь параметр Percent True в блоке Decide, а в параметрах счёта установим число репликаций – 1 и длину репликации (Replication Length) – 15 часов. Посмотрев отчёт после окончания счёта, можно заметить, что заметно возросло число клиентов, обслуживаемых в парикмахерской, которая, по-видимому, теперь работает пятнадцать часов вместо десяти. Этого не должно быть, так как в расписании ArrivalSchedule прибытие клиентов прекращается после десяти часов. Можно догадаться, что после десяти часов работы расписание прибытия клиентов начинает повторяться. Чтобы проверить это, активизируем модуль Schedule и откроем окно расписания. Нажмём в нём кнопку Options. Появится диалоговое окно, изображённое на рис. 3.23. В нём вы видите параметры установки осей X и Y расписания. В поле Time slot duration (Единичный временной интервал) можно выбрать масштаб оси X. В поле Range (time slots) (Диапазон) устанавливается число единичных интервалов, показываемых в окне. Параметром Calendar speed (slots per click) устанавливается скорость прокрутки окна расписания (число единичных интервалов, прокручивающихся за один щелчок клавишей ). Для оси Y можно установить величину максимума и минимума диапазона значений, а также минимальную величину, на которую мы можем изменять скорость прибытия (в поле Snap spa­cing). Отметка в окне Snap grid lines (Вертикальная сетка) позволяет отображать вертикальные линии сетки масштабирования.

Н

Рис. 3.23. Окно настройки параметров расписания

Рис. 3.24. Изменения в диалоговом окне Schedule

ас сейчас интересует раздел When at end of schedule (Что делать, если расписание закончилось). Пометка Repeat from beginning (Начать сначала) означает, что расписание начнёт повторяться, а пометка Remain at arrival rate (Оставить на уровне), которую надо установить, позволит оставить тот уровень прибытия, который мы зададим в находящемся рядом окне (установим в нём нулевое значение). Преобразовать расписание мы могли бы и другим способом, т.е. через диалог. Если мы воспользуемся таблицей для внесения изменений в расписание, то в диалоговое окно изменения будут внесены автоматически, и наоборот. Мы можем убедиться в этом, открыв окно диалога (рис. 3.24) и увидев в нём новую строчку: «0, infinite». Выполнив счёт и посмотрев отчёт, мы можем увидеть, что обнаруженный недостаток модели исправлен. Таким образом, мы получили некоторый опыт анализа модели. Далее можно заняться её совершенствованием.